Protocolo SNMP

1
PROTOCOLO SNMP
Introduccin
En una internet se conectan varias redes entre s con el uso de routers y un

protocolo de interconexin de redes, de modo que los routers usan el protocolo para
encubrir las caractersticas de las redes y proporcionar un servicio uniforme entre
ellas, es decir, aunque cada red use una tecnologa distinta y unas reglas especficas
de transmisin, los hosts de cada red ven a la red de igual manera. Este es el poder
de la abstraccin de la interconexin entre redes.
La principal tecnologa de interconexin de redes es el conjunto de protocolos de

Internet llamados TCP/IP, que se crearon en la Agencia de Proyectos de Investigacin
Avanzada de Defensa (DARPA) y que son los que se usan en la Red Internet, (con
mayscula, la red de redes global) pero tambin en la interconexin de redes menores
internet, (con minscula, redes locales).
SNMP se sita en el tope de la capa de transporte de la pila OSI, o por encima de la

capa UDP de la pila de protocolos TCP/IP. Siempre en la capa de transporte.
Grficamente se podra ver as:
Aplicacin
SNMP
Transporte(TCP,UDP,..
.)
Interred(IP)
Interfase de red
Fsica
1. Necesidad de administrar redes
Los problemas que se presentan en la interconexin de redes son

principalmente dos:
1. Dispositivos diferentes: La interconexin de redes permite diferentes tipos

de dispositivos y estos son de distintos vendedores, todos ellos soportando el
protocolo TCP/IP. Debido a esto, la administracin de redes se presenta como
un problema. Sin embargo, usar una tecnologa de interconexin abierta
permiti que existieran las redes formadas por dispositivos de distintos
fabricantes, por lo que para administrar estas redes, habr que usar una
tecnologa de administracin de redes abierta.
2. Administraciones diferentes: Como se permite la interconexin entre redes

de distinto propsito y distinto tamao, hay que tener en cuenta que tambin
estn administradas, gestionadas y financiadas de distinta forma.
.- Evolucin Histrica del Protocolo Simple de Gestin de Red (SNMP)

2
El protocolo Snmpv1 fue diseado a mediados de los 80 por Case,

McCloghrie, Rose, and Waldbusser, como una solucin a los problemas de
comunicacin entre diferentes tipos de redes.
En un principio, su principal meta era el lograr una solucin temporal hasta la

llegada de protocolos de gestin de red con mejores diseos y mas completos.
Pero esos administradores de red no llegaron y SNMPv1 se convirti en la
nica opcin para la gestin de red.
El manejo de este protocolo era simple, se basaba en el intercambio de

informacin de red a travs de mensajes(PDUs). Adems de ser un protocolo
fcilmente extensible a toda la red, debido a esto su uso se estandarizo entre
usuarios y empresas que no queran demasiadas complicaciones en la gestin
de sus sistemas informticos dentro de una red.
No obstante este protocolo no era perfecto, adems no estaba pensado para

poder gestionar la inmensa cantidad de redes que cada da iban apareciendo.
Para subsanar sus carencias surgi la versin 2 (SNMP v2). Las mayores
innovaciones respecto a la primera versin son:
Introduccin de mecanismos de seguridad, totalmente ausentes en la

versin 1. Estos mecanismos protegen la privacidad de los datos,
confieren autentificacin a los usuarios y controlan el acceso.
Mayor detalle en la definicin de las variables.
Se aaden estructuras de la tabla de datos para facilitar el manejo de los
datos. El hecho de poder usar tablas hace aumentar el nmero de
objetos capaces de gestionar, con lo que el aumento de redes dejo de
ser un problema.
Realmente esta versin 2 no supuso mas que un parche, es ms hubo

innovaciones como los mecanismos de seguridad que se quedaron en pura
teora, no se llegaron a implementar. Por estas razones, este ao se ha
producido la estandarizacin de la versin 3. Con dos ventajas principales
sobre sus predecesores:
Aade algunas caractersticas de seguridad como privacidad,

autentificacin y autorizacin a la versin 2 del protocolo.
Uso de Lenguajes Orientados a Objetos(Java, C++) para la construccin
de los elementos propios del protocolo(objetos). Estas tcnicas
confieren consistencia y llevan implcita la seguridad, por lo que ayudan
a los mecanismos de seguridad.
Captulo 2: Conceptos
El entorno usado para administracin en los protocolos de Internet se llama

Internet-standard Networking Management Framework (Entorno para la
administracin de redes basadas en Internet), y esto se debe a motivos
histricos: Los esquemas previos eran ocasionales y propietarios. Actualmente
3
existen dos versiones de este entorno: El entorno original (Internet-standard

Networking Management Framework), compuesto por tres documentos, cada
uno de los cuales es un estndar de Internet con la condicin de
Recomendado; y el entorno que le sucedi (SNMPv2 Framework), formado por
doce documentos. Dos aos despus, ste segundo entorno se reviso en ocho
documentos, quedando algunos como borradores de estndares y otros como
proposiciones de estndares. Con el tiempo, estos documentos se convirtieron
en un completo estndar de Internet. Fue entonces cuando se declar histrico
el estndar original y la comunidad se qued con un solo entorno. Entre ambos
entornos hubo dos pasos intermedios: SNMP Security y SMP, que fueron
incluidos dentro del entorno SNMPv2, dejando sus documentos originales slo
para inters histrico.
1. Un Modelo
Un sistema de administracin de red contiene cinco elementos:
Uno o ms nodos administrables, conteniendo cada uno un agente.

Al menos una estacin de administracin de red (NMS) con soporte para
una o ms aplicaciones de administracin de la red.
Posiblemente una o ms entidades de doble funcin, que pueden actuar
tanto como agente o como administrador.
Un protocolo de administracin de red, que es usado por la estacin y
los agentes para intercambiar informacin.
Informacin que administrar.
1.1 Nodos Administrables
Un nodo administrable es un dispositivo tal que puede clasificarse un una de

las tres siguientes categoras:
Un Host, como una estacin de trabajo, mainframe, o impresora;

un sistema de enrutamiento; o
un dispositivo de acceso al medio, como un repetidor, un puente o un
hub.
Estas tres categoras coinciden en que clasifican a algn tipo de dispositivo

con alguna capacidad de trabajo en red. Las dos primeras categoras se
caracterizan por ser normalmente independientes del medio, mientras que la
principal caracterstica de los dispositivos de la tercera clase es la dependencia
del medio.
1.1.1 El Axioma Fundamental

4
Un buen sistema de administracin de red debe conocer la diversidad

de dispositivos existentes y proporcionar un entorno apropiado. As,
el axioma fundamental dice que:
El impacto de aadir una administracin de red a un nodo

administrable debe ser mnima, reflejando un comn
denominador ms bajo.
El axioma fundamental se debe a las grandes diferencias entre los

distintos nodos administrables que existen.
1.1.2 Caractersticas de los Nodos Administrables
Podemos considerar que cada nodo administrable est formado por tres
componentes:
Funciones de usuario.
Un protocolo de administracin, que permite monitorizar y controlar el
nodo administrable.
Instrucciones de administracin, que interactan con la implementacin
del nodo administrable para permitir la monitorizacin y el control.
La interaccin entre estos tres componentes es sencilla: Las instrucciones

actan como un pegamento entre las funciones de usuario y el protocolo de
administracin: Esto se debe a un mecanismo de comunicacin interno en el
que las estructuras de datos de las funciones de usuario deben ser accesibles
y modificables a peticin del protocolo de administracin.
1.1.3 Modelo Administrativo
Actualmente los intercambios de informacin son insuficientes para

proporcionar la administracin de los nodos. El protocolo de administracin
trabaja en el entorno del modelo administrativo, que mantiene polticas de
autorizacin y autentificacin. Esto permite determinar al nodo como se est
administrando, de modo que slo los procesos de aplicaciones autorizadas
realicen la administracin.
1.2 Estacin de Administracin de Red
Una estacin de administracin de red es una mquina que ejecuta el

protocolo de administracin de red y una o ms aplicaciones de
administracin de red. Si el protocolo es el encargado de proporcionar
los mecanismos de administracin, entonces las aplicaciones
determinan la poltica que se usa para la administracin.
El Axioma Fundamental indica que aadir administracin de red

debera tener un impacto mnimo en los nodos; en consecuencia la
carga se desplaza a las estaciones. Sin embargo podramos pensar que
el sistema que soporta la estacin de administracin es ms potente que
un nodo, as que cunta potencia es necesaria entonces?. La
5
experiencia muestra que la mayora de las estaciones de trabajo pueden

proporcionar los recursos necesarios para soportar una buena estacin
de administracin.
Hay que tener en cuenta que a medida que hay ms nodos

administrables en una internet, se favorece desplazar la carga hacia la
estacin de administracin.
1.2.1 Entidades de doble funcin
Se ha dicho que las estaciones de administracin slo interactan con

los nodos. Qu pasara si el mismo nodo tambin fuera una estacin de
administracin? Es necesario apreciar que el modelo agente-
administrador puede soportar directamente esto si consideramos que el
software de cada estacin de administracin puede realizar tanto la
funcin de administrador como la de agente, es decir, que el modelo
agente-administrador es tambin un modelo peer-to-peer.
Teniendo esto en cuenta, se pueden construir relaciones jerrquicas

entre las estaciones de administracin. Por ejemplo, se puede construir
un sistema de administracin donde cada segmento de una LAN tiene
una aplicacin de administracin que controla el estado de los
dispositivos de ese segmento; estas aplicaciones deberan informar a
aplicaciones de estaciones de administracin regionales, las cuales
deberan informar a estaciones de administracin entre empresas. En
este ejemplo, el software de cada estacin realiza un papel de
administrador al monitorizar y controlar dispositivos que dependen de l
jerrquicamente, y un papel de agente al informar y actuar segn los
comandos proporcionados por un superior jerrquico.
Hay que hacer significar que el concepto clave con las entidades de
doble funcin es que la relacin jerrquica depende de la configuracin,
mientras que la relacin peer-to-peer depende de la arquitectura.
1.3 Protocolo de Administracin de Red
Dependiendo del paradigma que se utilice para la administracin de la

red, existen varias formas que puede tomar un protocolo de
administracin.
1.3.1 Operaciones
En el entorno de administracin, cada nodo tiene una serie de variables, de

modo que leyendo estas variables se monitoriza el nodo, y cambindoles el
valor se controla. Se trata de un paradigma de depuracin remota, cuya ventaja
es que es sencillo construir un protocolo de administracin que realice estas
funciones.
6
Adems de las operaciones de lectura y escritura, existen otras dos:
Una operacin cruzada, que permite determinar a la estacin de

administracin qu variables soporta un nodo.
Una operacin de interrupcin, que permite a los nodos informar a la
estacin de administracin de un evento extraordinario.
Veamos un poco ms de ambas operaciones.
1.3.1.1 Operacin de Examen
Como los nodos realizan distintas funciones, tambin contienen diferentes

variables de administracin. En el entorno de administracin, todas las
variables relacionadas con una determinada funcionalidad se agrupan juntas.
Las estaciones deben determinar qu variables se soportan. Sin embargo, el
protocolo debe proporcionar un significado para examinar la lista de variables
soportadas por un nodo.
Tambin hay que tener en cuenta que pueden existir variables que aparezcan
ms de una vez. Por ejemplo, la tabla de enrutamiento IP no es escalar, sino
que est formada por una o ms filas, cada una de las cuales presenta varias
columnas. Por tanto, el protocolo de administracin debe proporcionar dos
nuevas funciones:
Un mecanismo para recuperar celdas de una tabla.

Un mecanismo para recuperar nmeros grandes de una celda de una
tabla.
1.3.1.2 Operacin de Interrupcin
Desde el comienzo de los sistemas operativos, siempre se ha debatido

acerca de utilizar un mtodo de interrupcin o un mtodo de sondeo.
Esta discusin tambin se realiza en la administracin de redes. Los
argumentos para cada uno de estos mtodos son los siguientes:
Con el mtodo basado en interrupciones, tenemos las siguientes

ventajas: Cuando ocurre un evento extraordinario, el nodo enva una
interrupcin a la estacin de administracin adecuada (suponiendo que
el dispositivo no ha cado y se puede alcanzar la estacin). Por tanto
tenemos la ventaja de una notificacin inmediata.
Con el mtodo basado en interrupciones, tenemos las siguientes
desventajas: Requiere recursos para generar la interrupcin ya que si la
interrupcin debe contener mucha informacin, el nodo perder tiempo
en prepararla y no se dedicar a cosas tiles. Por supuesto, cuando se
genera una interrupcin, el agente asume que la aplicacin de
administracin est preparada para recibir la informacin. Por tanto hay
que usar un diseo cuidadoso para que las interrupciones sean
recibidas slo por aquellas estaciones interesadas. Ms an, si ocurre
un evento extraordinario, las interrupciones pueden ocupar un gran
ancho de banda, lo cual es poco deseable si se est informando de un
7
problema de congestin de la red. Por eso se refina el mtodo de las

interrupciones de modo que un nodo slo informa cuando la ocurrencia
de un evento sobrepasa un determinado umbral, pero esto implica que
el agente debe gastar tiempo para determinar cundo debe generar una
interrupcin. Es decir, el mtodo basado en interrupciones tiene un
fuerte impacto en el agente, en la red o en ambos. En conclusin, como
los nodos tienen una pequea visin de toda la red, es conveniente que
las aplicaciones de administracin detecten el problema de alguna otra
forma.
Con el mtodo basado en sondeo, una aplicacin de administracin
pregunta peridicamente al nodo cmo van las cosas, as el control lo
tiene la aplicacin, la cual s tiene una visin global de la red.
La desventaja del mtodo de sondeo es que la aplicacin de
administracin no sabe qu elementos sondear ni con qu frecuencia: Si
el intervalo de frecuencia es breve, se ocupa mucho ancho de banda, y
si es muy largo, la respuesta a eventos catastrficos es demasiado
lenta. Otra desventaja es el trfico que se introduce en la red, por lo que
la aplicacin de administracin debe tener recursos de almacenamiento
adicionales para ello.
En el entorno de administracin se usa el modelo interrupcin-sondeo directo

(trap-directed polling). Cuando ocurre un evento extraordinario, el nodo manda
una interrupcin simple a la aplicacin. La aplicacin es entonces la
responsable de iniciar conversaciones con el nodo para determinar la
naturaleza y la extensin del problema. Esto es muy efectivo ya que el impacto
creado en los nodos es pequeo, en el ancho de banda es mnimo y los
problemas se resuelven en el momento oportuno. Por tanto, las interrupciones
actan como una alarma previa, y se usa un sondeo de baja frecuencia.
1.3.2 Forma de transporte
La eleccin de un servicio de transporte por parte del protocolo de

administracin es importante ya que de los mecanismos internos del servicio de
transporte depende la efectividad del protocolo, y de acuerdo con el Axioma
Fundamental, hay que elegir la forma de comunicacin menos impactante en el
proceso.
La aplicacin de administracin es la que debe decidir el nivel de fiabilidad

deseado e implementar el algoritmo apropiado, sin dejar esta decisin en
manos del servicio de transporte. De esta manera, el nodo tendra menos carga
debido a esta eleccin. Todo esto conduce a elegir un servicio de transporte no
orientado a conexin. Esta eleccin implica un comportamiento "sin
preocupaciones" por parte del agente y permite a la aplicacin controlar el nivel
de fiabilidad.
Hay otro motivo para elegir servicios de transporte no orientados a conexin.

Cuando la red est congestionada y es difcil establecer una conexin, un
protocolo orientado a conexin realiza sta en tres pasos. Si la red est
perdiendo paquetes, es ms difcil establecer este modo de conexin que otro
modo de un solo paso. Por tanto es conveniente usar la segunda forma, ya que
8
en esos casos es cuando realmente la red necesita ser controlada y

administrada.
1.4 Informacin de Administracin
Finalmente, hemos de explicar la informacin a intercambiar entre la estacin

de administracin y el nodo utilizando el protocolo de administracin. Una
unidad de informacin de administracin se denomina objeto administrado
(managed object), y un conjunto de dichos objetos se denomina Mdulo de
Base de Informacin de Administracin (Mdulo MIB).
La caracterstica ms importante de los mtodos usados para describir la

informacin de administracin es la extensibilidad, de modo que se pueda
comenzar con un pequeo conjunto de definiciones, para aumentarlo segn
crezcan las necesidades.
Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos

pueden aadir sus propios objetos para mejorar sus productos, lo que puede
influir en la estandarizacin de la tecnologa de administracin.
1.4.1 Objetos Administrados (Managed Objects)
La instrumentacin de administracin acta entre los protocolos del

dispositivo y el protocolo de administracin, tomando la informacin del
dispositivo y presentndola como un conjunto de objetos administrados. Esta
coleccin se denomina Recursos Objeto del Agente.
1.4.2 Revisin del Modelo Administrativo
Anteriormente se present el modelo administrativo como el responsable de

proporcionar polticas de autorizacin y autentificacin. Ahora tambin
podemos aadir que es el modelo administrativo el que determina qu
aplicacin de administracin puede acceder a qu objeto y con qu
operaciones. Las operaciones de administracin permitidas a una aplicacin
por un agente se denomina poltica de acceso; la coleccin de objetos
administrados que son visibles para estas operaciones se denomina Vista del
MIB, o simplemente Vista.
1.4.3 Relaciones de tipo Proxy
A veces, un agente accede a informacin de administracin no local. Cuando

otro agente recibe la peticin de esa informacin, realiza una serie de
operaciones para satisfacer la solicitud. Esto se denomina Interaccin de
delegacin (interaccin Proxy) y el agente que la realiza se denomina Agente
delegado (Agente Proxy).
Hay varias razones por las que utilizar las relaciones Proxy:
9
Cortafuegos Administrativo(Firewall): Puede ser til que el agente proxy

autentifique y autorice las peticiones para no cargar a un dispositivo
ocupado con estas tareas. As, el agente proxy implementa una poltica
administrativa extensiva, y el dispositivo slo responde a las peticiones
realizadas por el agente.
Caching Firewall: Puede ser til que el agente proxy tenga la
informacin a modo de cach, tambin para minimizar la carga del
dispositivo.
Puentes de transporte: En una red multiprotocolo, un dispositivo
soportara el servicio punto a punto de solo un conjunto de protocolos.
Idealmente, una estacin de administracin soportara los servicios
punto a punto de todos los conjuntos de protocolos. De todas maneras,
un agente proxy que soporte servicios punto a punto del conjunto
apropiado de protocolos puede utilizarse para establecer un camino para
las comunicaciones de administracin entre el dispositivo y la estacin.
Traducciones de protocolo: En el caso en que los dispositivos no
soporten protocolos de administracin, las peticiones usadas en el
protocolo son traducidas a una forma entendida por el dispositivo. De
igual forma, las respuestas son traducidas a la forma entendida por el
protocolo.
Una propiedad importante de las relaciones tipo proxy es el principio de

transparencia. La idea es aparentar que la aplicacin se est comunicando
directamente con el agente real, es decir, una aplicacin simplemente
especifica los recursos deseados y el agente proxy es el encargado de hacer
que las cosas salgan bien, como si la informacin de administracin la tuviera
el agente proxy localmente.
1.5 En perspectiva
El Axioma Fundamental del entorno de administracin se basa en la nocin

de distribucin universal:
Si se ve la administracin de redes como un aspecto esencial, entonces

debera distribuirse en la mayor cantidad de dispositivos de la red.
Como hay muchos ms agentes que estaciones de administracin, entonces

minimizando el impacto de la administracin en los agentes, podremos
solucionar el problema.
Otro principio importante es que la administracin de red es distinta a

cualquier otra aplicacin:
Cuando todo falla, la administracin de red debe seguir funcionando.
Este principio indica que muchas de las funciones que se encuentra en la

capa de transporte, sern directamente direccionadas por aplicaciones en la
estacin de administracin, teniendo en cuenta que sern las propias
aplicaciones las que definan el grado de fiabilidad requerido de cada operacin.
10
Sin embargo, el servicio de transporte no debe "ayudar", slo debera ser la

forma ms simple de permitir atravesar la red.
Captulo 3: Modelo de Informacin
Para examinar el papel de la informacin de gestin en el entorno de

administracin, consideraremos las siguientes cinco partes:
Reglas para definir la informacin de administracin.

Ejemplos de colecciones de definiciones existentes.
Reglas para definir los convenios textuales (definicin de tipos de uso
frecuente).
Cmo se accede a stas al definir informacin de administracin.
Coexistencia entre el entorno original y el entorno SNMPv2.
Antes de comenzar, hay que aclarar la relacin entre variables, objetos y tipos de
objetos. Un objeto administrable tiene asociado una sintaxis y una semntica de tipo
abstracto, mientras que una variable es una instancia de un objeto particular; en este
caso tambin se denomina instancia de un objeto.
Estructura de la Informacin de Administracin
La Estructura de la Informacin de Administracin (SMI) define las reglas para

definir la informacin de administracin independientemente de los detalles de
implementacin. La SMI se define usando ASN.1 (Abstract Syntax Notation).
Si se piensa que una coleccin de objetos administrados estn almacenados, por

ejemplo, en una base de datos, la SMI define el esquema de esa base de datos. En
realidad, esa base de datos se denomina Base de Informacin de Administracin
(MIB).
ndice para este punto:
1.- Mdulos de informacin
2.- Definiciones de objetos
3.- Convenciones textuales
4.- Refinamiento de la sintaxis
5.- Grupos de objetos
6.- Identificando una instancia de un objeto
7.- Definiciones de notificaciones
8.- Ejemplos de uso
9.- Revisin de un mdulo MIB

11
1 Mdulos de Informacin
Existen tres clases de mdulos ASN.1, tambin llamados Mdulos de Informacin,

definidos por el SMI:
Mdulos MIB, que define una coleccin de objetos de administracin afines.

Sentencias de Conformidad, que definen un conjunto de requisitos de los
nodos con respecto a uno o ms mdulos MIB.
Sentencias de Capacidad, que describe la capacidad de un nodo para
implementar los objetos definidos en uno o ms mdulos MIB.
Por supuesto, estas funciones deberan estar combinadas en un slo mdulo.
1.1 Identificando un Mdulo de Informacin
Cada mdulo de informacin debe comenzar con la indicacin de su identidad y la

historia de sus revisiones. Para ello, la SMI define una macro especial (MODULE-
IDENTITY):
MODULE-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"LAST-UPDATED" value(Update UTCTime)
"ORGANIZATION" Text
"CONTACTO-INFO" Text
"DESCRIPTION" Text
RevisionPart
VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
RevisionPart ::= Revisions | empty
Revisions ::= Revision | Revisions Revision
Revision ::=
12
"REVISION" value(Update UTCTime)
"DESCRIPTION" Text
-- se usa el juego de caracteres ASCII NVT
Texto ::= """"string""""
END
La macro MODULE-IDENTITY se usa para mantener los histricos de las revisiones

de cada mdulo de informacin. Debe existir una y slo una en cada mdulo de
informacin.
1.1.1 Clusula LAST-UPDATED
La clusula LAST-UPDATED, que debe existir, contiene la fecha y hora de la ltima

revisin realizada sobre este mdulo de informacin.
1.1.2 Clusula ORGANIZATION
La clusula ORGANIZATION, que debe existir, contiene una descripcin textual de la

organizacin bajo cuyo auspicio se desarroll este mdulo de informacin.
1.1.3 Clusula CONTACT-INFO
La clusula CONTACT-INFO, que debe estar presente, contiene el nombre, direccin

postal, nmero del telfono, y la direccin de correo electrnico de la persona a quien
deben ser enviadas las preguntas de carcter tcnico relacionadas con este mdulo
de informacin.
1.1.4 Clusula DESCRIPTION
La clusula DESCRIPTION, indispensable, contiene una descripcin textual de alto

nivel de los contenidos de este mdulo de informacin.
1.1.5 Clusula REVISION
La clusula REVISION, que no es necesaria, es usada normalmente para describir

las revisiones hechas al mdulo de informacin, en orden inverso a su sucesin
cronolgica. Cada instancia de esta clusula contiene la fecha y hora de la revisin.
13
La clusula DESCRIPTION, que debe estar presente por cada clusula REVISION,
contiene una descripcin textual de alto nivel de la revisin identificada en esa clusula
REVISION.
1.1.7 Valor de MODULE-IDENTITY
El valor devuelto de una llamada a la macro MODULE-IDENTITY es un identificador

de objetos (OBJECT IDENTIFIER). Como tal, este valor puede usarse al referirse al
mdulo de informacin que contiene la llamada.
1.1.8 Ejemplo de uso
Ejemplo de cmo podra construirse el esqueleto de un mdulo MIB:
FIZBIN-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, experimental
FROM SNMPv2-SMI;
fizbin MODULE-IDENTITY
LAST-UPDATED "9210070433Z"
ORGANIZATION "IETF SNMPv2 Grupo de trabajo"
CONTACT-INFO
" Marshall T. Rose
Postal: Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186,
US
Tel: +1 415 968 1052

14
Fax: +1 415 968 2510
E-mail: mrose@dbc.mtview.ca.us "
DESCRIPTION
"Mdulo MIB para entidades SNMPv2."
REVISION "9210070433Z"
DESCRIPTION
"Versin inicial de este mdulo MIB."
::= { snmpModules 1 }
END
1.2 Uso de OBJECT IDENTIFIERs
Un identificador de objeto es un nombre asignado arbitrariamente. Los

identificadores de objetos definidos en el SMI para el protocolo de gestin son:
-- camino al root
internet OBJECT IDENTIFIER ::= {iso 3 6 1}
directory OBJECT IDENTIFIER ::= {internet 1}
mgmt OBJECT IDENTIFIER ::= {internet 2}
experimental OBJECT IDENTIFIER ::= {internet 3}
private OBJECT IDENTIFIER ::= {internet 4}
enterprises OBJECT IDENTIFIER ::= {private 1}
security OBJECT IDENTIFIER ::= {internet 5}
snmpV2 OBJECT IDENTIFIER ::= {internet 6}
-- dominios de transporte
snmpDomains OBJECT IDENTIFIER ::= {snmpV2 1}
-- proxies de transporte
snmpProxys OBJECT IDENTIFIER ::= {snmpV2 2}

15
-- entidades mdulo
snmpModules OBJECT IDENTIFIER ::= {snmpV2 3}
La raz del subrbol administrada por la Autoridad de Nmeros Asignados para Internet
(IANA) es:
Internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
Es decir, el subrbol de Internet de identificadores de objetos comienza con el prefijo:
1.3.6.1.
Varias ramas debajo de este subrbol se usan para la gestin de la red:
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
Sin embargo, el SMI no prohibe la definicin de objetos en otras porciones del rbol de
objetos.
El subrbol mgmt(2) es usado para identificar objetos "estndar".
El subrbol experimental(3) es usado para identificar objetos diseados por grupos

de trabajo del IETF. Si un mdulo de informacin producido por un grupo de trabajo se
convierte en un mdulo de informacin "estndar", entonces en el momento de su
entrada en los cauces estndar de Internet, los objetos se mueven al subrbol
mgmt(2).
El subrbol private(4) se usa para identificar objetos definidos de forma unilateral. El

subrbol enterprises(1) bajo el private se usa, entre otras cosas, para permitir a los
proveedores de subsistemas de red registrar modelos de sus productos.
El subarbol snmpV2 se usa con propsitos de mantenimiento.
1.3 Identificando un Punto de Registro
Los identificadores de objeto se usan frecuentemente en el funcionamiento del

protocolo, y existe una macro para asociar informacin textual con asignaciones de
identificadores, que es la macro OBJECT-IDENTITY:
OBJECT-IDENTITY MACRO::=
BEGIN
16
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
Status ::= "current" | "deprecated" | "obsolete"
ReferPart ::= "REFERENCE" Text | empty
Text ::= """" string """"
END
La macro OBJECT-IDENTITY se usa para definir informacin sobre la asignacin de

un identificador de objeto. La expansin de la macro OBJECT-IDENTITY
conceptualmente sucede durante la implementacin y no en tiempo de ejecucin.
1.3.1 Clusula STATUS
La clusula STATUS, que debe estar presente, indica si esta definicin es actual o
histrica.
La clusula DESCRIPTION, obligatoria, contiene una descripcin textual de la

asignacin del objeto.
1.3.3 Clusula REFERENCE
La clusula REFERENCE, que no es necesaria, contiene una referencia cruzada

textual a una asignacin del objeto definida en algn otro mdulo de informacin.
1.3.4 Valor de OBJECT-IDENTITY
El valor devuelto en una llamada a la macro OBJECT-IDENTITY es un identificador de

objeto (OBJECT IDENTIFIER).
1.3.5 Ejemplo de uso
Ejemplo de cmo podra hacerse una asignacin de un identificador de objeto:
fizbin69 OBJECT-IDENTITY
STATUS current
DESCRIPTION
17
"La identidad autoritaria del chipset Fizbin 69."
::= { fizbinChipSets 1 }
2 Definiciones de Objetos
La macro OBJECT-TYPE se usa para definir un objeto gestionado. La expansin de

la macro OBJECT-TYPE conceptualmente sucede durante la implementacin y no en
tiempo de ejecucin. La definicin de la macro es:
OBJECT-TYPE MACRO::=
BEGIN
TYPE NOTATION ::=
"SINTAX" type(Syntax)
UnitsPart
"MAX-ACCESS" Access
"STATUS" Status
"DESCRIPTION" Text
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE ObjectName)
UnitsPart ::= "UNITS" Text | empty
Access ::= "no-accesible"
| "solo-lectura "
| "lectura y escritura"
| "lectura y creacin "
Status ::= "actual"
| "desaprobado"
| "obsoleto"
18
ReferPart ::= "REFERENCIA" Text | empty
IndexPart ::= "NDICE" "{" IndexTypes "}"
| "INCREMENTOS" "{" Entry "}"
| empty
IndexTypes ::= IndexType | IndexTypes "," IndexType
IndexType ::= "IMPLIED" Index | Index
Index ::=
-- utiliza el valor de SYNTAX
-- de la correspondiente
-- llamada OBJECT-TYPE
value ( Indexobject ObjectName)
Entry ::=
--Utiliza el valor de INDEX de la
--correspondiente llamada OBJECT-TYPE
value (Entryobject ObjectName)
DefValPart ::="DEFVAL" "{" value(Defval Syntax) "}"
| empty
-- usa el juego de caracteres NVT ASCII
Texto ::= """" string """"
END
2.1 Clusula SINTAX
La clusula SINTAX, que debe estar presente, define las estructuras de datos
abstractas correspondientes a ese objeto. La estructura de datos debe ser una de las
alternativas definidas en ObjectSyntax.
Se permiten la creacin de subtipos de ASN.1, as como adaptar los tipos de ASN.1,

principalmente como una ayuda a los implementadores para mejorar la
comprensibilidad del objeto. Cualquier restriccin en tamao, rango, enumeraciones o
19
repertorio especificados en esta clusula representan el nivel mximo de apoyo que

tiene "sentido en el protocolo". Por supuesto, no est permitida la creacin de subtipos
para los tipos Counter32 o Counter64, pero se permite para el tipo Gauge32(estos
tipos se explican posteriormente).
La semntica de ObjectSyntax es:
ObjectSyntax ::=
CHOICE {
Simple SimpleSyntax,
--Las sucesiones (SEQUENCES) para las

tablas
--y filas conceptuales no se mencionan

aqu...
application-wide ApplicationSyntax
-- tipos integrados en ASN.1
SimpleSyntax ::=
CHOICE {
--Los enteros con un rango ms restrictivo
--tambin pueden ser usados
integer-value INTEGER (-
2147483648..2147483647),
string-value OCTECT STRING,
objectID-value OBJECT IDENTIFIER,
--slo se permiten formas enumeradas
bit-value BIT STRING
--indistinguible del ENTERO, pero nunca es

necesario
--ms de 32-bits para una representacin en

20
--complemento a dos
Integer32 ::=
[UNIVERSAL 2]
IMPLICIT INTEGER (-2147483648..2147483647)
-- tipos propios de la aplicacin
ApplicationSyntax ::=
CHOICE {
ipAddress-value IpAddress,
counter-value Counter32,
gauge-value Gauge32,
timeticks-value TimeTicks,
arbitrary-value Opaque,
nsapAddress-value NsapAddress,
big-counter-value Counter64,
unsigned-integer-value UInteger32
--en orden del byte de red
--(ste es un tipo etiquetado por
-- razones histricas)
IpAddress ::=
[APLICACIN 0]
IMPLICIT OCTECT STRING (SIZE (4))
--contador ciclico
Counter32 ::=
[APLICACIN 1]
21
IMPLICIT INTEGER (0 ..4294967295)
--contador fijo( no cicla)
Gauge32 ::=
[APLICACIN 2]
-- centsimas de segundos desde una poca
TimeTicks ::=
[APLICACIN 3]
-- slo para compatibilidad con lo anterior
Opaque ::=
[APLICACIN 4]
IMPLICIT OCTECT STRING
-- para el direccionamiento NSAP de OSI
--(tipo etiquetado por razones histricas)
NsapAddress ::=
[APLICACIN 5]
IMPLICIT OCTET STRING (SIZE (1 | 4 ..21))
--para contadores que dan la vuelta en menos de
--una hora con slo 32 bits
Counter64 ::=
[APLICACIN 6]
-- cantidad de 32-bits sin signo
UInteger32 ::=
22
[APLICACIN 7]
A continuacin pasamos a comentar brevemente cada tipo de dato usado en la

definicin anterior.
2.1.1 Integer32 e INTEGER
El tipo Integer32 representa informacin de valor entero entre -2 31 y 231-1 inclusive (-

2147483648 a 2147483647 decimal). Este tipo es indistinguible del tipo INTEGER.
El tipo INTEGER tambin puede usarse para representar informacin de valor

entero, si contiene enumeraciones numricas, o si se crea un subtipo para restringir
ms que el tipo Integer32. En el caso anterior, slo esas enumeraciones de nmeros
pueden estar presentes como un valor. Aunque se recomienda que los valores
enumerados empiecen en 1 y estn numerados de forma consecutiva, cualquier valor
vlido para Integer32 es permitido como valor enumerado y, adems, los valores
enumerados no necesitan ser asignados de forma consecutiva.
Finalmente, el carcter guin no se permite como una parte del nombre de ninguna
enumeracin de nmeros.
2.1.2 OCTET STRING
El tipo OCTET STRING representa datos binarios o textuales arbitrarios. Aunque

SMI no especifica ninguna limitacin del tamao para este tipo, los diseadores de
MIB deben comprender que puede haber limitaciones en la implementacin e
interoperabilidad para tamaos superiores a 255 octetos.
2.1.3 OBJECT IDENTIFIER
El tipo OBJECT IDENTIFIER representa administrativamente a los nombres

asignados. Cualquier instancia de este tipo puede tener, como mucho, 128
subidentificadores. Adems, cada subidentificador no debe exceder el valor 232-1
(4294967295 decimal).
2.1.4 BIT STRING
El tipo BIT STRING representa una enumeracin de bits. Esta coleccin contendr
valores no negativos, consecutivos y comenzando por el cero. Slo esos bits
23
enumerados pueden estar presentes en un valor.
Un requisito en los mdulos MIB "estndar" es que el carcter guin no est

permitido como parte del nombre de una enumeracin de bits.
2.1.5 IpAddress
El tipo IpAddress representa una direccin internet de 32-bits. Esta es representada

como un OCTET STRING de longitud 4, en formato de red.
El tipo IpAddress es un tipo etiquetado por razones histricas. Deben representarse

las direcciones de red usando una llamada a la macro TEXTUAL-CONVENTION.
2.1.6 Counter32
El tipo Counter32 representa un entero no negativo que se incrementa de forma

montona hasta el valor mximo de 2 32-1 (4294967295 decimal), cuando se alcanza
dicha cifra, se vuelve al cero y se incrementa de nuevo.
Los contadores no tienen definido un valor "inicial", y as, un valor de un Contador

slo no representa (en general) ningn volumen de informacin. Suelen ocurrir
discontinuidades en el incremento montono del valor en la reinicializacin del sistema
de gestin, y en otros ocasiones como se especific en la descripcin de un tipo de
objeto que usa este tipo ASN.1. Si los otros casos pueden ocurrir, por ejemplo, la
creacin de una instancia de objeto en un momento distinto al de la reinicializacin,
entonces el objeto correspondiente debe definirse con un valor de clusula SINTAX de
TimeStamp indicando el tiempo de la ltima discontinuidad.
El valor de la clusula MAX-ACCESS para los objetos con un valor de Counter32 de

su clusula SINTAX es siempre de slo lectura.
La clusula DEFVAL no est permitida para los objetos con un valor de su clusula
SINTAX de Counter32.
2.1.7 Gauge32
El tipo Gauge32 representa un entero no negativo que puede aumentar o disminuir,

pero nunca exceder un valor mximo. El valor mximo no puede superar 232-1
(4294967295 decimal). El mximo valor de un Gauge ser siempre el valor mximo
que la informacin que contiene pueda alcanzar; si la informacin contenida disminuye
por debajo del mximo valor, el Gauge tambin disminuye.
2.1.8 TimeTicks
24
El tipo TimeTicks representa un entero no negativo que representa el tiempo, modulo

232 (4294967296 decimal), en centsimas de un segundo, entre dos pocas. Cuando
se definen objetos que usan este tipo, la descripcin del objeto identifica las dos
pocas a las que se hace referencia.
Por ejemplo, se define el convenio textual de TimeStamp qu est basado en el tipo

TimeTicks. Con un TimeStamp, la primera referencia a una poca se define como
cuando sysUpTime del MIB-II era cero, y la segunda referencia a una poca se define
como el valor actual de sysUpTime.
2.1.9 Opaque
El tipo Opaque se mantiene por compatibilidad con lo anterior, y no se usar para los
tipos de objetos recientemente definidos.
El tipo Opaque posee la capacidad para pasar sintaxis arbitraria. Un valor es

codificado usando las Reglas de Codificacin Bsicas de ASN.1 en una cadena de
bytes. Esto, a su vez, es codificado como un OCTET STRING, envolviendo
doblemente el valor original.
Se ha de notar que una implementacin apropiada necesita slo aceptar y reconocer

datos codificados de forma opaca. No es necesario poder decodificar los datos y
entonces interpretar su contenido.
Un requisito para los mdulos MIB "estndar" es que ningn objeto puede tener un
valor de clusula SINTAX de Opaque.
2.1.10 NsapAddress
El tipo NsapAddress representa una direccin OSI como una extensin de variable
OCTET STRING. El primer byte de la cadena contiene un valor binario en el rango
0..20, e indica la longitud en bytes de NSAP. Despus del primer octeto, est el NSAP,
expresado en notacin binaria, comenzando por el byte ms significativo. Una longitud
cero de NSAP se usa como una direccin "especial" que significa "NSAP por defecto"
(anlogo a la direccin de IP 0.0.0.0). Aunque la direccin de valor 0 de una direccin
NSAP se representa con un byte el resto de las direcciones NSAP son codificadas en,
al menos, 4 bytes.
El tipo NsapAddress es un tipo etiquetado por razones histricas. Deben

representarse las direcciones de red mediante una llamada a la macro TEXTUAL-
CONVENTION.
2.1.11 Counter64
El tipo Counter64 representa un entero no negativo que el aumenta de forma

montona hasta alcanzar el valor mximo de 2 64-1 (18446744073709551615 decimal),
25
cuando supera ese valor, se comienza de nuevo desde cero.
Los contadores no tienen definido valor inicial, y as, un solo valor de un Contador no
tiene, en general, ningn valor de informacin. Discontinuidades en la monotona
creciente del valor del contador normalmente viene provocada por la reinicializacin
del sistema de gestin, y tambin al especificar la descripcin de un tipo de objeto que
usa este tipo de dato. Si alguna de estas situaciones ocurre, por ejemplo, la creacin
de una instancia de un objeto en un momento distinto al de la reinicializacin, entonces
el objeto correspondiente debe definirse con un valor de clusula SINTAX de
TimeStamp indicando el tiempo de la ltima discontinuidad.
El valor de la clusula de MAX-ACCESS para los objetos con un valor de Counter64

en su clusula SINTAX siempre es de slo lectura ("read-only").
Un requisito en los mdulos MIB estndar es que el tipo Counter64 slo puede
usarse si la informacin a contener diera la vuelta en menos de una hora usando el
tipo Counter32.
La clusula DEFVAL no est permitida para objetos con un valor de Counter64 en

su clusula SINTAX.
2.1.12 UInteger32
El tipo UInteger32 representa informacin de valor entero entre 0 y 2 32-1 inclusive (0

a 4294967295 decimal). Se trata de un valor entero sin signo.
2.2 Clusula UNITS
La clusula UNITS, que no es obligatoria, contiene una definicin textual de las

unidades asociada con ese objeto.
2.3 Clusula MAX-ACCESS
La clusula MAX-ACCESS, que debe estar presente, define si tiene privilegios para
leer, escribir y/o crear una instancia del objeto. ste es el mximo nivel de acceso para
el objeto. (Este nivel mximo de acceso es independiente de cualquier poltica
administrativa de accesos.)
El valor "read-write" (lectura-escritura) indica que est permitida la lectura y la

escritura, pero no la creacin. Un valor "read-create" (lectura-creacin) indica
posibilidad de lectura, escritura y creacin. Un valor de "not-accessible" indica o un
objeto auxiliar o un objeto que slo es accesible por una notificacin.
Estos valores estn ordenados de menor a mayor: "not-accessible", "read-only", "read-

write", "read-create".
Si algn objeto en una fila conceptual tiene "read-create" como su nivel mximo de
acceso, entonces ningn otro objeto de la misma fila conceptual puede tener un nivel
mximo de acceso de "read-write". ("read-create" est por encima de "read-write".)
2.4 Clusula STATUS

26
La clusula STATUS, que debe estar presente, indica si esta definicin es actual o
antigua.
Los valores "actual", y "obsoleto" son suficientemente explcitos. El valor

"desaprobado" (deprecated) indica que el objeto est obsoleto, pero que un
implementador puede desear dotar al objeto de interoperabilidad con aplicaciones
anteriores.
2.5 Clusula DESCRIPTION
La clusula DESCRIPTION, de carcter obligatorio, contiene una definicin textual

de ese objeto que mantiene todas las definiciones semnticas necesarias para la
implementacin, y debe incluir cualquier informacin que pudiera ser comunicada de
otro modo en cualquier comentario asociado con el objeto.
2.6 Clusula REFERENCE
La clusula REFERENCE, que no es necesaria, contiene una referencia cruzada

textual a un objeto definido en algn otro mdulo de informacin. Esto es til cuando
se usan mdulos MIB no OSI producidos por alguna otra organizacin.
2.7 Clusula INDEX
La clusula INDEX, que debe estar presente si ese objeto corresponde a una fila
conceptual (a menos que una clusula AUGMENTS se encuentre explcitamente
presente), y debe estar ausente en cualquier otro caso, define informacin de
identificacin de instancia para los objetos subordinados a este objeto.
Las funciones de gestin son slo aplicables a objetos escalares. Sin embargo, es
conveniente para desarrolladores de aplicaciones de gestin imponer estructuras
imaginarias, en forma de tabla en la coleccin ordenada de objetos que constituyen el
MIB. Cada tabla conceptual contiene cero o ms filas, y cada fila puede contener uno
o ms objetos escalares, llamados los objetos columna. Esta conceptualizacin es
formalizada usando la macro OBJECT-TYPE para definir el objeto que se corresponde
con una tabla y el objeto que se corresponde con una fila en esa tabla. Una tabla
conceptual tiene la siguiente sintaxis:
SEQUENCE OF <EntryType>
donde <EntryType> se refiere al tipo de la sucesin de su fila conceptual

subordinada. Una fila conceptual tiene la siguiente sintaxis:
<EntryType>
donde <EntryType> es el tipo de la sucesin definida de la forma:
<EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }

27
donde hay un tipo para cada objeto subordinado, y cada <type> es de la forma:
<descriptor> <sintax>
donde <descriptor> es el descriptor del objeto subordinado, y <sintax> tiene el valor

de la clusula SINTAX de ese objeto subordinado, opcionalmente se omite la
informacin de los subtipos. Adems, estos tipos siempre estn presentes (las
clusulas DEFAULT y OPTIONAL no estn permitidas en la deficicin de la sucesin).
La clusula MAX-ACCESS para las filas y tablas conceptuales es "not-accessible."
Para objetos que no son objetos columna, las instancias del objeto son identificadas
aadiendo un subidentificador cero al nombre de ese objeto. Por otra parte, la clusula
INDEX del objeto fila conceptual superior a un objeto columna define informacin de
identificacin de instancia.
La informacin de identificacin de instancia en una clusula INDEX debe especificar

objeto/s cuyo/s valor/es pueda/n distinguir inequvocamente una fila conceptual. La
sintaxis de esos objetos indica cmo hacer un identificador de instancia:
1. integer-valued: un solo subidentificador toma un valor entero (esto slo es vlido

para enteros no negativos);
2. string-valued, cadenas de longitud fija (o de longitud variable si va precedida por

la palabra IMPLIED): n subidentificadores, donde n es la longitud de la cadena
(cada byte de la cadena es codificado en un subidentificador separado);
3. string-valued, cadenas de longitud fija (o variable si va precedida de la palabra

IMPLIED): n+1 subidentificadores, donde n es la longitud de la cadena (el primer
subidentificador es n, seguido del cual, cada byte de la cadena va codificado en
un subidentificador separado);
4. object identifier-valued: n+1 subidentificadores, donde n es el nmero de

subidentificadores en el valor (el primer subidentificador es n, y despus, cada
subidentificador en el valor se copia);
5. IpAddress-valued: 4 subidentificadores, en la notacin a.b.c.d.
6. NsapAddress-valued: n subidentificadores, donde n es la longitud del valor

(cada byte del valor se codifica en un subidentificador por separado);
Las palabras clave IMPLIED pueden estar slo presentes para objetos que tienen
una sintaxis de longitud variable (ej., las cadenas de longitud variable o los objetos de
identificador valorado). Adems, las palabras clave IMPLIED pueden aparecer, a lo
sumo, una vez dentro de la clusula INDEX, y en ese caso, es asociado con el objeto
ms a la derecha que tiene una sintaxis de longitud variable. Finalmente, las palabras
clave IMPLIED no pueden usarse en un objeto cadena de longitud variable si esa
cadena puede tener un valor de longitud cero.
28
Las instancias identificadas por el uso de objetos de valor entero (integer-valued)

deben ser numerados empezando desde uno (no desde cero). Se debe evitar el uso
de cero como un valor para un objeto ndice de valor entero, exceptuando casos
especiales.
Los objetos que son especificados en la clusula INDEX de una fila conceptual y
tambin los objetos columna de la misma la fila conceptual son denominados objetos
auxiliares. La clusula MAX-ACCESS para los objetos auxiliares recientemente
definidos es no accesible ("not-accessible"). Sin embargo, una fila conceptual debe
contener al menos un objeto columna que no es un objeto auxiliar (es decir, el valor de
la clusula MAX-ACCESS para estos objetos es "read-only" o "read-create").
Los objetos especificados en una fila conceptual de la clusula INDEX no necesitan

ser objetos columna de esa fila conceptual. En esta situacin, la clusula
DESCRIPTION de la fila conceptual debe incluir una explicacin textual de cmo los
objetos que son incluido en la clusula INDEX pero no los objetos columna de esa fila
conceptual, son usados como instancias identificadoras de los objetos columna de la
fila conceptual.
2.7.1 Creacin y eliminacin de filas conceptuales
Para las recientemente definidas filas conceptuales, que permiten la creacin de

instancias nuevas de objetos y la eliminacin de instancias de objetos existentes, debe
haber un objeto columna con un valor de clusula SINTAX de RowStatus y un valor de
clusula MAX-ACCESS de "read-create". Se suele llamar a ste conjunto, estado para
la fila conceptual.
2.8 Clusula AUGMENTS
La clusula AUGMENTS, de carcter no obligatorio a menos que el objeto se

corresponda con una fila conceptual, es una alternativa a la clusula INDEX. Cada
objeto que corresponde a una fila conceptual o tiene una clusula INDEX o una
clusula AUGMENTS.
Si un objeto correspondiente a una fila conceptual tiene una clusula INDEX, esa fila
se denomina "una fila conceptual base"; por otra parte, si el objeto tiene una clusula
AUGMENTS, la fila se dice que es "una fila conceptual aumentada", donde la clusula
AUGMENTS nombra el objeto correspondiente a la fila conceptual base que es
aumentada por esta extensin de la fila conceptual. Se identifican instancias de
objetos columna subordinados de una extensin de una fila conceptual mediante la
clusula INDEX de la fila conceptual base que corresponde al objeto nombrado en la
clusula AUGMENTS. Adems, las instancias de objetos columna subordinados de
una extensin de una fila conceptual existen segn la misma semntica de instancias
de objetos columna subordinados de la fila conceptual base aumentada. De sta
forma, la creacin de una fila conceptual base implica la creacin de la
correspondiente fila conceptual aumentada.
Por ejemplo, un diseador de MIB podra desear definir columnas adicionales en un

MIB particular en el que lgicamente extiende una fila conceptual de un MIB estndar.
La definicin de la fila conceptual del MIB estndar incluira la clusula INDEX y el MIB
29
particular contendra la definicin de una fila conceptual que usa la clusula

AUGMENTS.
Una fila conceptual base puede ser aumentada por mltiples extensiones de filas
conceptuales.
2.8.1 Relacin entre las clusulas INDEX y AUGMENTS
Al definir informacin de identificacin de instancia para una tabla conceptual:
Si hay una correspondencia uno-a-uno entre las filas conceptuales de esta

tabla y una tabla existente, entonces debe usarse la clusula AUGMENTS.
Si no, si hay una relacin dispersa entre las filas conceptuales de esta tabla y
una tabla existente, entonces debe usarse una clusula INDEX se igual forma
que en la tabla existente.
Si no, deben definirse objetos auxiliares dentro de la fila conceptual para la
nueva tabla, y esos objetos deben usarse dentro de la clusula INDEX para la
fila conceptual.
2.9 Clusula DEFVAL
La clusula DEFVAL, que es necesario que est presente, define un valor aceptable
por defecto que puede ser usado por una entidad SNMPv2 que realiza el papel de
agente cuando se crea una instancia de objeto.
Durante la creacin de la fila conceptual, si una instancia de un objeto columna no

est presente como uno de los operandos en la correspondiente operacin del
protocolo de gestin, entonces el valor de la clusula de DEFVAL, si est presente,
indica un valor por defecto que puede usar una entidad SNMPv2 que acta en el papel
de agente.
El valor de la clusula DEFVAL debe, por supuesto, corresponderse con el de la

clusula SINTAX para el objeto. Si el valor es un identificador de objeto (OBJECT
IDENTIFIER), entonces debe expresarse como un solo identificador, y no como una
coleccin de subidentificadores.
Si un operando de una operacin del conjunto del protocolo de gestin es una

instancia de un objeto de slo lectura, entonces ser devuelto el error NotWritable. De
esta forma, la clusula DEFVAL puede usarse para proporcionar un valor por defecto
aceptable que pueda usar una entidad SNMPv2 acta en el papel de agente.
Como ejemplo, considere las posibles clusulas DEFVAL siguientes:
ObjectSyntax clusula DEFVAL
Integer32 1 -- igual para Gauge32, TimeTicks, UInteger32
INTEGER valid -- valor enumerado
OCTET STRING ffffffffffff' H

30
OBJECT IDENTIFIER sysDescr
BIT STRING { primary, secondary } -- valores enumerados
IpAddress 'c0210415' H --192.33.4.21
Los tipos de objeto con valores de Counter32 y Counter64 en su clusula SINTAX,

no pueden tener clusulas DEFVAL, ya que ellos no han definido valores iniciales. Sin
embargo, se recomienda que se inicialicen a cero.
2.10 Valor de OBJECT-TYPE
El valor devuelto por una llamada a la macro OBJECT-TYPE es el nombre del

objeto, que es un identificador de objeto (OBJECT IDENTIFIER), un nombre asignado
administrativamente.
Cuando un identificador de objeto es asignado a un objeto:
Si el objeto corresponde a una tabla conceptual, entonces es una sola

asignacin, que para una fila conceptual, est inmediatamente presente bajo
ese objeto. El nombre asignado administrativamente para el objeto de la fila
conceptual se obtiene aadiendo un subidentificador "1" al nombre asignado
administrativamente para la tabla conceptual.
Si el objeto corresponde a una fila conceptual, entonces por lo menos una
asignacin, una para cada columna en la fila conceptual, est presente bajo
ese objeto. El nombre asignado administrativamente para cada columna se
obtiene aadiendo un nico subidentificador positivo al nombre asignado
administrativamente para la fila conceptual.
Si no, ningn otro identificador de objeto de menor orden, puede ser asignado
al objeto.
El subidentificador final de cualquier nombre asignado administrativamente para un

objeto ser positivo. Un subidentificador final de valor cero est reservado para futuros
usos.
Adems, aunque las tablas y filas conceptuales son nombres asignados

administrativamente dados, estos objetos conceptuales no pueden ser manipulados de
forma conjunta por el protocolo de gestin.
2.11 Ejemplo de uso
Considere cmo se podra definir una tabla conceptual y sus subordinadas.
EvalSlot OBJECT-TYPE
31
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"El nmero de ndice de la primera entrada no asignada en la

tabla de evaluacin.
Una estacin de gestin debe crear nuevas entradas en la tabla

de evaluacin usando este algoritmo: primero, emitir una
operacin de recuperacin del protocolo de gestin para
determinar el valor de evalSlot; y, segundo, emitir una operacin
para crear una instancia del objeto evalStatus poniendo su valor
a underCreation(1). Si esta ltima operacin tiene xito,
entonces la estacin de gestin puede continuar modificando las
instancias correspondientes a la fila conceptual recientemente
creada, sin miedo a colisin con otra estacion de gestin".
::= { eval 1 }
evalTable OBJECT-TYPE
SYNTAX SEQUENCE OF EvalEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Tabla (conceptual) de evaluacin."
::= { eval 2 }
evalEntry OBJECT-TYPE
SYNTAX EvalEntry
STATUS current
DESCRIPTION
"Entrada (fila conceptual) en la tabla de evaluacin."

32
INDEX { evalIndex }
::= { evalTable 1 }
EvalEntry ::= SEQUENCE {
evalIndex Integer32,
evalString DisplayString,
evalValue Integer32,
evalStatus RowStatus
evalIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESO not-accessible
STATUS current
DESCRIPTION
"La variable auxiliar usada para identificar instancias de los

objetos columna en la tabla de evaluacin."
::= { evalEntry 1 }
evalString OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Cadena para evaluar."
::= { evalEntry 2 }
evalValue OBJECT-TYPE
SYNTAX Integer32
33
STATUS current
DESCRIPTION
"Valor cuando evalString fue ejecutado por ltima vez."
DEFVAL {0}
::= { evalEntry 3 }
evalStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"La columna de estado usada para crear, modificar, y borrar

instancias de los objetos columna en la tabla de evaluacin."
DEFVAL { active }
::= { evalEntry 4 }
2.12 Tipos Construidos
El SMI define dos tipos construdos:
row: tipo de dato de la forma
<row> ::=
SEQUENCE {
<tipo 1>
.......
<tipo n>
donde cada <tipo x> es un tipo simple o especfico de la aplicacin.
table: de la forma
34
<table> ::=
SEQUENCE OF <row>
Una tabla, completamente instanciada, ser bidimensional, con cero o ms filas,

cada una de ellas con el mismo nmero de columnas.
3. Convenciones Textuales
Aunque los tipos de datos especficos de la aplicacin contenidos en el SMI son

usados, la experiencia en la creacin de mdulos MIB muestra que, a veces, es
convieniente definir tipos de datos con sintaxis similar a la estndar, pero con una
semntica mucho ms precisa. Estos tipos, se denominan convenciones textuales. Su
codificacin es idntica a la de los otros tipos, pero dentro del MIB, poseen una
semntica especial, la cual es capturada por la macro TEXTUAL-CONVENTION:
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION ::=
DisplayPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" type(Syntax)
VALUE NOTATION ::= value(VALUE Syntax)
DisplayPart ::= "DISPLAY-HINT" Text | empty
Status ::= "current" | "deprecated" | "obsolete"
--Usa el conjunto de caracteres ASCII NVT
Text ::= """"string""""
END
Esta macro no se invoca de la misma forma que el resto:

35
<descriptor> <macro> <clusulas> ::= <valor>
sino que es de la forma:
<descriptor> ::= TEXTUAL-CONVENTION <clusulas> <tipo syntax>
Ejemplo:
DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Representa informacin textual, y ningn objeto puede superar los 255

caracteres de longitud"
SYNTAX OCTET STRING (SIZE (0..255))
3.1.1 Clusula DISPLAY-HINT
Indicacin de cmo un valor entero o cadena correspondiente a esta convencin

textual, puede ser interpretado para su representacin por pantalla.
3.1.2 Clusula STATUS
Indicacin del estado de la convencin textual.
Explicacin textual de la convencin.
3.1.4 Clusula REFERENCE
Si la convencin textual es una derivacin de otra, entonces esta clusula est

presente e incluye una referencia textual a la otra convencin.
3.1.5 Clusula SYNTAX
Sintaxis asociada con el tipo de dato.
3.2 Convenciones Textuales Predefinidas
Existen convenciones textuales predefinidas, ya que son comunes a la mayor parte

36
de las aplicaciones, como pueden ser:
DisplayString: cadena de hasta 255 caracteres NVT ASCII
OCTET STRING (SIZE (0..255))
Su valor de DISPLAY-HINT sera 255 (se interpreta como una cadena de 255
bytes)
PhysAddres:
OCTET STRING
Su DISPLAY-HINT asociado sera 1x:, que es interpretado como: imprimir cada

octeto como un nmero hexadecimal seguido del carcter ":"
TruthValue: un valor booleano
INTEGER { true(1), false(2) }
DateAndTime: una especificacin temporal:
OCTET STRING (SIZE (8 | 11))
Su DISPLAY-HINT asociado es: 2d-1d-1d-,1d:1d:1d:1d.1d,1a1d:1d, que

determina un formato de fecha y hora de la forma:
1992-2-29,17:45:20.3,+4:0
4. Refinamiento de la Sintaxis
Algunas macros permiten refinar la sintaxis de un objeto (ej., la clusula SYNTAX de

la macro MODULE-COMPLIANCE). Sin embargo, no todos los refinamientos de
sintaxis son apropiados. En particular, las primitivas del objeto o el tipo de aplicacin
no se debe cambiar.
Adems, se aplican las siguientes restricciones:
Restricciones a Refinamiento en
Sintaxis del objeto Rango Enumerado Tamao Repertorio

37
INTEGER (1) (2) - -
OCTET STRING - - (3) (4)
OBJECT IDENTIFIER - - - -
BIT STRING - (2) - -
IpAddress - - - -
Counter32 - - - -
Gauge32 (1) - - -
TimeTicks - - - -
NsapAddress - - - -
Counter64 - - - -
donde:
1. El rango de valores permitidos puede ser refinado aumentando los lmites

inferiores, reduciendo los lmites superiores, y/o reduciendo las opciones de
valor/rango alternativas;
2. La enumeracin de valores con nombre puede refinarse quitando uno o ms

valores con nombre;
3. El tamao en caracteres del valor puede ser refinado aumentando los lmites
38
inferiores, reduciendo los lmites superiores, y/o reduciendo las opciones de

tamao alternativas;
4. El repertorio de caracteres en el valor puede ser reducido mediante el uso de

subtipos.
No existen otros mtodos de refinamiento.
Al refinar un objeto con un valor de clusula SYNTAX de Integer32 o UInteger32, el

valor refinado de SYNTAX se expresa como un INTEGER y se consideran las
restricciones de la tabla superior.
5. Grupos de Objetos
Se definen objetos afines dentro de grupos de objetos (object group). Desde el punto
de vista de la implementacin, un grupo de objetos se ve como una unidad de
implementacin, y un desarrollador puede codificar cero o ms objetos de los
contenidos en el grupo.
La asignacin de identificadores de objeto a los tipos en un mdulo MIB, sigue la

siguiente pauta:
1. Los tipos de objeto se ponen dentro de grupos de objetos
2. Un identificador de objeto es asignado a cada grupo. Por

convenio, se suele anteponer al nombre, como prefijo, el
nombre del mdulo MIB.
3. Los objetos poseen un identificador secuencial subordinado al

del grupo.
6. Identificando una Instancia de un Objeto
Es necesario conocer el nombre de un objeto, para poder gestionarlo, pero los

objetos en s no son ms que plantillas, y son las instancias de los mismos, las que
maneja el protocolo, con lo que se debe especificar el identificador de instancia.
El protocolo de gestin utiliza, para identificar instancias, un identificador de objeto,

formado por la concatenacin del nombre del tipo de objeto y un sufijo. Si el objeto no
es parte de una tabla, entonces, representa una instancia de un tipo de objeto en un
dispositivo particular. Para identificarlo slo hay que aadir al nombre del objeto, ".0".
Ejemplo:
"nombre de objeto".0
En caso de ser un objeto parte de una tabla, su identificacin posee tres posibles
alternativas dependiendo de:
El objeto es una tabla

El objeto es una fila de una tabla
El objeto es una columna de una fila de la tabla
39
El protocolo no permite manejar objetos agregados, con lo que slo se pueden

gestionar objetos columna que forman las celdas de una tabla.
7 Definiciones de Notificaciones
La macro NOTIFICATION-TYPE se usa para definir la informacin contenida dentro

de una transmisin no solicitada de informacin de gestin (es decir, dentro de una
SNMPv2-Trap-PDU o InformRequest-PDU).
La definicin de la macro es la siguiente:
NOTIFICATION-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::= "OBJETOS" "{" Object "}"| empty
Objetos ::= Objeto | Objects "," Object
Objeto ::= value(Name ObjectName)
Status ::= "actual" | "desaprobado" | "obsoleto"
--usa el juego de caracteres NVT ASCII
Text ::= """" string """"
END
7.1 Clusula OBJECTS

40
La clusula OBJECTS, no obligatoria, define la sequencia ordenada de

objetos del MIB que estn contenidos dentro de cada instancia de la
notificacin.
7.2 Clusula STATUS
La clusula STATUS, que debe existir, indica si esta definicin es actual o

antigua ("current" u "obselete" respectivamente).
El valor "deprecated" (desaprobada) indica que la notificacin est obsoleta,

pero que un implementador puede desear dotar al objeto de interoperabilidad
con aplicaciones ms viejas.
7.3 Clusula DESCRIPTION
La clusula DESCRIPTION, que debe estar presente, contiene una definicin

textual de la notificacin que mantiene todas las definiciones semnticas
necesarias para la implementacin, y debe incluir cualquier informacin que
pueda ser comunicada en cualquier notificacin asociada con el objeto. En
particular, la clusula DESCRIPTION debe documentar qu instancias de los
objetos mencionados en la clusula OBJECTS deben ser contenidas dentro de
las notificaciones de este tipo.
7.4 Clusula REFERENCE
La clusula REFERENCE, no obligatoria, contiene una referencia cruzada de

tipo textual a una notificacin definida en algn otro mdulo de informacin. Se
usa si se tiene un mdulo MIB no OSI, producido por alguna otra organizacin.
7.5 Valor de NOTIFICATION-TYPE
El valor devuelto en una llamada a la macro NOTIFICATION-TYPE es el

nombre de la notificacin, que es un identificador de objeto (OBJECT
IDENTIFIER), un nombre asignado administrativamente.
8. Ejemplo de uso
Vase cmo podra describirse un trap linkUp:
LinkUp NOTIFICATION-TYPE
OBJECTS { ifIndex }
STATUS current
DESCRIPTION
41
"Un trap linkUp significa que la entidad SNMPv2 que acta bajo
el papel de agente, reconoce que uno de los enlaces de
comunicacin representados en su configuracin ha surgido".
::= { snmpTraps 4 }
Segn esta llamada, la interrupcin (trap) identificada como
{ snmpTraps 4 }
es usada para informar del establecimiento de un enlace.
Una entidad SNMPv2 que acta como un agente puede configurarse para enviar a
esta interrupcin a cero o ms entidades SNMPv2 gestoras, dependiendo del
contenido de las tablas aclTable y viewTable. Por ejemplo, por uso juicioso de
viewTable, una entidad agente SNMPv2 podra configurarse para enviar todas las
interrupciones del linkUp a una entidad particular, y las interrupciones de tipo linkUp
para slo ciertas interfaces a otras entidades.
9. Revisin de un Mdulo MIB
9.1 Modificando Definiciones de Objetos
Cuando se modifica la definicin de tipo de un objeto existente, hay cambios que son
factibles sin necesidad de cambiar las asignaciones de identificadores de objetos:
Si la clusula SYNTAX utiliza un tipo enumerado. Ej:

Debe aadirse una clusula UNITS
(SYNTAX INTEGER { up(1), down(2) }
entonces se aaden enumeraciones:
(SYNTAX INTEGER { up(1), down(2), testing(3) }
y deben cambiarse las etiquetas asociadas.
La clusula STATUS debe

modificarse:
De "current" a
"deprecated" u
"obsolete"
De
"deprecated" a
"obsolete"
42
Una clusula REFERENCE

debe ser aadida, o en
caso de estar presente,
modificada.
Una clusula DEFVAL debe
ser aadida o cambiada,
segn corresponda.
Por otra parte, si previamente la semntica de cualquier objeto predefinido se

cambia (es decir, si se hace un cambio especficamente a alguna clusula distinta de
las especificadas anteriormente como posibles), entonces el objeto asociado con dicho
identificador tambin debe cambiarse.
Ese cambio del descriptor asociado con un objeto existente es considerado un

cambio semntico, estas cadenas pueden ser usadas en una declaracin IMPORTS.
Finalmente, si un objeto tiene el valor de su clusula STATUS cambiado, entonces el

valor de su clusula DESCRIPTION, debe ser actualizado de forma acorde.
9.2 Modificando la Definicin de las Notificaciones
Las reglas para modificar una notificacin son simples: debe aadirse o cambiarse
una clusula REFERENCE, pero si se realiza un cambio profundo, debe definirse un
nuevo tipo notificacin.
Mdulos MIB
1. Las Diferentes Clases de Mdulos MIB
Existen tres tipos de mdulos MIB:
Estndar: Diseados por un grupo de trabajo del IETF(Internet Engineering task

force) y estandarizado por el IESG(Internet Engineering Steering Group). Los prefijos
de los identificadores de objetos se encuentran bajo el subrbol mgmt.
Experimental: Mientras un grupo de trabajo desarrolla un MIB, los identificadores de

objetos temporales se colocan bajo el subrbol experimental. Si el MIB adquiere la
condicin de estndar, se colocan los identificadores bajo el subrbol mgmt.
Especfico: La mayor parte de las empresas desarrollan mdulos MIB propios que
soporten ciertas caractersticas particulares, las cuales no son generalmente
contempladas en los mdulos MIB estndar.
2. MIB Internet-standard
En el protocolo original, el MIB estndar Internet defina el conjunto fundamental de

objetos administrados por un dispositivo basado en TCP/IP (MIB-I). El documento fue
posteriormente revisado hasta llegar al MIB-II.
43
3. MIB SNMPv2
Parte de la instrumentacin para una entidad SNMPv2. Existen cinco grupos:
system: Grupo system (trado del MIB-II). Se trata de una coleccin de objetos
comunes a todos los sistemas de gestin
snmp: Grupo estadstico del SNMPv2
snmpCommunity: Grupo estadstico del SNMPv1
snmpSet: Grupo set del SNMPv2
snmpBasicNotification: Grupo de notificaciones bsico
3.1 Grupo System
Se trata de un conjunto fundamental de objetos administrados por un

dispositivo basado en TCP/IP. Son comunes para todos los sistemas.
System OBJECT IDENTIFIER ::= { mib-2 1 }
SysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
STATUS current
DESCRIPTION
"Una descripcin textual de la entidad. Este valor debera contener el nombre y

versin completos del tipo del hardware del sistema, sistema operativo, y
software de red."
::= { system 1 }
sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
STATUS current
DESCRIPTION
44
"La identificacin del vendedor del subsistema de red contenido en la entidad..

Este valor est almacenado dentro del subarbol de empresa SMI (1.3.6.1.4.1) y
provee de un mtodo sencillo para determinar qu se est gestionando. Por
ejemplo, si el vendedor es `Flintstones, Inc.' Asignado al subarbol
1.3.6.1.4.1.4242, ste podra asignar el identificador 1.3.6.1.4.1.4242.1.1 al
`Router Fred'."
::= { system 2 }
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
STATUS current
DESCRIPTION
"Tiempo (en centsimas de segundo) desde que la tuvo lugar la ltima

reinicializacin de alguna parte del sistema."
::= { system 3 }
sysContact OBJECT-TYPE
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Identificacin textual de la persona de contacto para este nodo gestionado,

junto con informacin de cmo contactar con esa persona. Si no se conoce
informacin de contacto, el valor ser una cadena de longitud cero."
::= { system 4 }
sysName OBJECT-TYPE
STATUS current
DESCRIPTION
"Un nombre asignado administrativamente para este nodo. Por convenio, este
el nombre de dominio. Si el nombre es desconocido, se pone una cadena de
longitud cero."
45
::= { system 5 }
sysLocation OBJECT-TYPE
STATUS current
DESCRIPTION
"Localizacin fsica de ste nodo (ej.:, 3rd floor). Si es desconocida, le valor de

ste campo es una cadena de longitud cero."
::= { system 6 }
sysServices OBJECT-TYPE
SYNTAX INTEGER (0..127)
STATUS current
DESCRIPTION
"Un valor que indique el conjunto de servicios que la entidad puede ofrecer
potencialmente. El valor ser una suma. La suma toma inicialmente el valor
cero, entonces, para cada capa, L, en el rango 1 a 7, para la que ste nodo
ejecuta transacciones, 2 elevado a (L - 1) es aadido a la suma. Por ejemplo,
un nodo que ejecuta slo funciones de enrutamiento podra tener un valor de 4
(23-1). Por el contrario, un nodo que es un host y ofrece servicios de aplicacin
podra tener el valor de 72 (2 4-1 + 27-1). En el contexto del conjunto de
protocolos internet, los valores deben ser calculados de acuerdo a:
layer functionality
1 physical (e.g., repeaters)
2 datalink/subnetwork (e.g., bridges)
3 internet (e.g., supports the IP)
4 end-to-end (e.g., supports the TCP)
7 applications (e.g., supports the SMTP)
Para sistemas que incluyen protocolos OSI, las capas 5 y 6 pueden adems
ser contadas."
::= { system 7 }
46
Ahora se introduce informacin de recursos de objetos: Una coleccin de

objetos que describen el soporte de las entidades SNMPv2, esttica y
dinmicamente configurables, de varios mdulos MIB
sysORLastChange OBJECT-TYPE
SYNTAX TimeStamp
STATUS current
DESCRIPTION
"El valor de sysUpTime en el momento del ltimo cambio de estado o valor de

cualquier instancia de sysORID."
::= { system 8 }
sysORTable OBJECT-TYPE
SYNTAX SEQUENCE OF SysOREntry
STATUS current
DESCRIPTION
"La tabla (conceptual) con la lista de capacidades de la entidad local SNMPv2

actuando como agente con respecto a varios mdulos MIB. Las entidades
SNMPv2 con soporte dinmicamente configurable de mdulos MIB tendrn un
nmero dinmicamente variable de filas conceptuales."
::= { system 9 }
sysOREntry OBJECT-TYPE
SYNTAX SysOREntry
STATUS current
DESCRIPTION
"Una entrada (fila conceptual) en sysORTable."

47
INDEX { sysORIndex }
::= { sysORTable 1 }
SysOREntry ::= SEQUENCE {
SysORIndex INTEGER,
SysORID OBJECT IDENTIFIER,
SysORDescr DisplayString,
SysORUpTime TimeStamp
sysORIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
STATUS current
DESCRIPTION
"Variable auxiliar usada para identificar instancias de objetos columna in

sysORTable."
::= { sysOREntry 1 }
sysORID OBJECT-TYPE
STATUS current
DESCRIPTION
"Identificacin autoritaria de la situacin de las capacidades con respecto a

varios mdulos MIB soportados por la entidad local SNMPv2 actuando como
agente."
sysORDescr OBJECT-TYPE
SYNTAX DisplayString
48
STATUS current
DESCRIPTION
"Descripcin textual de las capacidades identificadas por la instancia

correspondiente de sysORID."
sysORUpTime OBJECT-TYPE
SYNTAX TimeStamp
STATUS current
DESCRIPTION
"Valor de sysUpTime en el momento en el que esta fila conceptual fue

instanciada por ltima vez."
3.2 Grupo snmpSet
Este grupo define una coleccin de objetos que permiten a varias entidades
SNMPv2 cooperantes coordinar el uso de la operacin SET.
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
snmpInPkts OBJECT-TYPE
SYNTAX Counter32
STATUS current
DESCRIPTION
"Nmero total de mensajes enviados a la entidad SNMP desde la capa de

transporte."
::= { snmp 1 }
snmpInBadVersions OBJECT-TYPE
49
SYNTAX Counter32
STATUS current
DESCRIPTION
"Nmero total de mensajes SNMP que fueron enviados a la entidad SNMP y

eran para una versin no soportada de SNMP."
::= { snmp 3 }
snmpInBadCommunityNames OBJECT-TYPE
SYNTAX Counter32
STATUS current
DESCRIPTION
"Nmero total de mensajes SNMP enviados al la entidad SNMP que usaban un

nombre de comunidad SNMP desconocido para dicha entidad."
::= { snmp 4 }
snmpInBadCommunityUses OBJECT-TYPE
SYNTAX Counter32
STATUS current
DESCRIPTION
"Nmero total de mensajes SNMP enviados a la entidad que representaban

una operacion SNMP no permitida por la comunidad SNMP indicada en el
mensaje."
::= { snmp 5 }
snmpInASNParseErrs OBJECT-TYPE
SYNTAX Counter32
STATUS current
50
DESCRIPTION
"Nmero total de errores de ASN.1 o BER(Basic Encoding Rules)encontrados

por la entidad cuando decodificaba los mensajes SNMP recibidos."
::= { snmp 6 }
snmpEnableAuthenTraps OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
STATUS current
DESCRIPTION
"Indica si la entidad est autorizada para generar traps authenticationFailure. El

valor de este objeto est por encima de cualquier informacin de configuracin;
as como, provee un entorno por el cual todos los traps authenticationFailure
pueden ser deshabilitados.
Es muy recomendable que este objeto est almacenado en memoria no voltil,

ya que se debe mantener constante ante cualquier reinicializacin del sistema
de gestin de red."
::= { snmp 30 }
snmpSilentDrops OBJECT-TYPE
SYNTAX Counter32
STATUS current
DESCRIPTION
"Nmero total de GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-

PDUs, SetRequest-PDUs, e InformRequest-PDUs enviados a la entidad SNMP
que fueron silenciosamente eliminados porque el tamao de una respuesta
conteniendo una Response-PDU alternativa con un campo vaco de unin de
variables era mayor que otra restriccin local o el tamao mximo de mensaje
asociado con el origen de la respuesta."
::= { snmp 31 }
snmpProxyDrops OBJECT-TYPE
SYNTAX Counter32
51
STATUS current
DESCRIPTION
"Nmero total de GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-

PDUs, SetRequest-PDUs, e InformRequest-PDUs enviados a la entidad SNMP
que fueron eliminados porque la transmisin del (posiblemente traducido)
mensaje a un objetivo proxy fall de forma (distinto de un time-out) que no es
posible retornar un Response-PDU."
::= { snmp 32 }
3.3 Invocaciones de Tipo Estndar
El mdulo SNMPv2 tambin define tres "traps" estndar:
snmpTraps OBJECT IDENTIFIER ::= { snmpMIBObjects 5 }
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap coldStart significa que la entidad SNMPv2, actuando como agente, est
autoreinicializndose y su configuracin puede haber sido alterada."
::= { snmpTraps 1 }
warmStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap warmStart implica que la entidad SNMPv2, actuando como agente, est
autoreinicializndose de tal forma que su configuracin no cambia."
::= { snmpTraps 2 }
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"Un trap authenticationFailure significa que la entidad SNMPv2, en el papel de agente,

ha recibido un mensaje que no est apropiadamente autentificado. Mientras todas las
implementaciones de SNMPv2 deben ser capaces de generar este trap, el objeto
snmpEnableAuthenTraps indica cuando este trap ser generado."
52
::= { snmpTraps 5 }
Sentencias de Conformidad
En la declaracin original del protocolo, cada grupo de objetos llevaba un comentario

en ASN.1 indicando el nivel de conformidad asociado con el grupo.
Por ejemplo:
snmpCommunityGroup OBJECT-GROUP
OBJECTS { snmpInBadCommunityNames,snmpInBadCommunityUses }
STATUS current
DESCRIPTION
"Coleccin de objetos que proporcionan instrumentacin bsica de las

entidades SNMPv2 que soporten autenticacin basada en la comunidad."
::= { snmpMIBGroups 9 }
define un grupo de conformidad con 2 objetos. Un objeto puede estar en

varios grupos de conformidad. Un grupo de conformidad, es identificado por un
identificador de objeto, y es usado de dos formas: en definiciones de
requerimientos de conformidad y en definiciones de las extensiones
implementadas en un mdulo MIB.
3.1 MODULE-COMPLIANCE
Cuando la macro MODULE-COMPLIANCE es invocada, cero o ms mdulos

son identificados. Para cada mdulo, la clusula MANDATORY-GROUPS
identifica aquellos grupos que deben ser implementados. De forma similar, la
clusula GROUPS identifica los grupos que debes ser implementados si se
encuentra alguna condicin.
snmpBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Declaracin de conformidad para entidades SNMPv2 con

SNMPv2 MIB."
MODULE -- este mdulo
MANDATORY-GROUPS {snmpGroup,
snmpSetGroup,systemGroup,snmpBasicNotificationsGroup}
GROUP snmpCommunityGroup
53
DESCRIPTION
"Este grupo es preceptivo para entidades SNMPv2 que

soporten autentificacin basada en la comunidad."
::= { snmpMIBCompliances 1 }
Importando Definiciones de Macros
Todos los mdulos de informacin empiezan con una invocacin de la macro

MODULE-IDENTITY, que proporciona la lista de contactos y revisiones. Esta llamada
debe aparecer siempre despus de cualquier declaracin IMPORT o EXPORT.
Resumen
En este apartado se ha hablado de una parte fundamental de cualquier sistema, nos

referimos a las reglas que rigen la formacin de los distintos mdulos que forman el
sistema de gestin.
El SMI (Estructura de la informacin de administracin) nos ofrece las reglas para

definir la informacin de administracin independientemente de los detalles de
implementacin, la sintaxis usar ASN.1.
Existe tres tipos de mdulos de informacin definidos con las reglas ofrecidas por el
SMI:
Mdulo de Informacin Base (MIB): Conjunto fundamental de objetos de

administracin.
Sentencias de conformidad: Conjunto de requisitos de los nodos respecto a
uno o mas mdulos MIB.
Sentencias de capacidad: Capacidad de un nodo para implementar objetos
definidos en uno o ms mdulos MIB.
Cada mdulo de informacin debe comenzar con la indicacin de su identidad y la

historia de sus revisiones (macro MODULE-IDENTITY)
Dentro de cada modulo existirn objetos, los cuales se definen con la macro
OBJECT-TYPE, la expansin de estos se produce durante la implementacin.
Tambin se usaran convenciones textuales (macro TEXTUAL-CONVENTION), que
son redefiniciones mas precisas de algn tipo de datos, dentro de un MIB.
Existen tres tipos de MIB:
Estndar: son mdulos que se han convertido en un estndar.

Experimental: Esperan su oportunidad de convertirse en estndar.
Especfico: son propios de alguna empresa.
El modulo MIB de la V2 contiene 5 grupos de objetos: system, snmp,

snmpComunity, SnmpSet y SnmpBasicNotification.
54
Captulo 4: Modelo Administrativo
Consideraremos como se definen polticas administrativas para aplicaciones de

gestin y agentes. Esta parte de la red de gestin ha sufrido la mayor revisin desde la
introduccin de SNMP. Desafortunadamente todava no existe un consenso en la
solucin ms apropiada al problema.
1. Conceptos
En el entorno de gestin, una entidad SNMP es una "entidad lgica" en nombre de la

cual un agente o una aplicacin de gestin estn procesando un mensaje.
El entorno de gestin es responsable de proporcionar:
Autentificacin: se refiere a como las entidades SNMP identifican sus

mensajes.
Privacidad: se refiere a como las entidades SNMP protegen sus mensajes.
Autorizacin: se refiere a como una entidad agente SNMP determina los
objetos que son accesibles a una entidad de aplicacin de gestin dada, y las
operaciones que se pueden realizar en estos objetos.
1.1 Autentificacin
Cuando una entidad comienza una comunicacin, es configurada para suministrar

credenciales de autentificacin como una parte de la comunicacin. Dependiendo de
los mecanismos de autentificacin, sern vlidas tres clases de servicios:
Identificacin origen, por la cual un mensaje puede ser asociado con una
entidad origen.
Integridad del mensaje, por la cual un mensaje alterado puede ser detectado
con seguridad.
Proteccin limitada de retransmisin, por la cual un mensaje que ha sido
duplicado o retrasado por la red o una tercera parte puede ser detectado fuera
del tiempo de vida esperado del mensaje.
Tras esto podemos observar que prevenir las ocasiones de fuera de servicio, en las
cuales una tercera parte interrumpe una comunicacin, no es un objetivo del entorno
de gestin.
No obstante, para alcanzar seguridad con las anteriores funciones deberemos usar:
Encriptacin con firma,

Algoritmos (message digest)
Relojes incrementados montonamente.
1.2 Privacidad
Como las propiedades de autentificacin estn asociadas con la entidad enviadora,

las propiedades de privacidad se pueden asociar con las entidades receptoras.
Para lograr privacidad con seguridad, deberamos usar un algoritmo de encriptacin

55
y la clave asociada.
1.3 Autorizacin
Cuando un agente ejecuta una operacin, primero deber identificar la coleccin de

recursos de objetos de gestin a monitorizar. Si los recursos son accesibles mediante
algn mecanismo local, se dice que la operacin se desarrolla desde el punto de vista
del MIB, el cual es normalmente un conjunto adecuado de todos los objetos
gestionados controlados por una entidad. En cambio, si los recursos son accesibles
mediante el envo de mensajes SNMP a una entidad remota, entonces se dice que los
objetos son validos a travs de una relacin proxy.
Una vez que los recursos son identificados, solo resta determinar las operaciones
SNMP empleadas en ellos. A esto se denomina Poltica de Acceso, y es usada para el
control del flujo de informacin entre la entidad agente SNMP y una entidad de
aplicacin de gestin dada.
2. Comunidades
SNMP v2 est diseado para soportar mltiples entornos de administracin. El

entorno que veremos se denomina entorno de gestin basado en comunidades,
debido a que usa el concepto de comunidad empleado en el SNMP original.
SNMP define una comunidad como una relacin entre entidades SNMP. Una
comunidad SNMP se escribe como una cadena de octetos sin interpretacin. Esta
cadena se llama nombre de comunidad. Cada octeto toma un valor entre 0 y 255.
Cuando se intercambian mensajes SNMP, contienen dos partes:
Una cadena de comunidad, mandada en texto sencillo; y ,

Datos, conteniendo una operacin SNMP y los operandos asociados.
La cadena de comunidad es un simple manejador para las relaciones de gestin.

Ahora realizamos una valoracin de las propiedades de gestin de SNMP:
Identificacin origen: como las cadenas de comunidad son enviadas sin proteccin,
cualquier tercera parte capaz de interceptar un mensaje SNMP puede usar el mismo
nombre de comunidad y de esa forma demandar ser un miembro de la comunidad de
mensajes;
Integridad del mensaje: cualquier tercera parte puede modificar un mensaje SNMP
que intercepte.
Proteccin limitada de reenvos: cualquier tercera parte puede retrasar un mensaje

SNMP que haya interceptado;
Privacidad: cualquier tercera parte puede leer el mensaje SNMP que haya
interceptado;
Autorizacin: los agentes son responsables de mantener informacin local as como

56
los MIB que contiene, o las relaciones de proxy vlidas; ser sencillo para una tercera
parte obtener los accesos correctos de una entidad autorizada para monitorizar o
controlar esos objetos.
Para contemporizar, todo lo que puede ser dicho es que aunque SNMP v2 ofrece
enfoques tcnicos para estos asuntos, sus mecanismos no llevan a solucin. Adems
el grupo de trabajo ha sido incapaz de lograr un consenso en como llegar a la
solucin.
Naturalmente, el mercado se ha adaptado a estas carencias:
Primero, varios diseadores de mdulos MIB son reacios a definir objetos, que
maliciosamente modificados puedan causar considerables dificultades en la
red; y,
Muchos implementadores de agentes no han implementado funciones de
control SNMP a propsito.
3. Procedimientos
Veremos como se procesan los mensajes SNMP. Para empezar, veremos el formato
del mensaje. Existen tres partes:
Versin: el nmero de versin del mensaje.

Comunidad: la cadena de comunidad; y,
Datos: una operacin SNMP, definido como una estructura PDUs
3.1 Originando un mensaje
Usando conocimiento local, la entidad origen comienza seleccionando la comunidad

apropiada la cual tiene la autorizacin adecuada para usar las operaciones y el acceso
a los objetos MIB deseados. Luego:
Una estructura de mensaje es construida desde esta informacin;

Es convertida en una cadena de octetos; y,
Es enviada a la direccin de transporte de la entidad receptora.
3.2 Recibiendo un mensaje
Cuando un paquete es recibido del servicio de transporte, el contador (snmpInPkts)

es incrementado. Luego el paquete es examinado para ver si es una representacin
de una estructura de mensaje.
Si no es una representacin de una estructura de mensaje, el contador

(snmpInASNParseErrs) es incrementado y el paquete es descartado. En caso
afirmativo, la versin del mensaje es revisada para ver si se refiere a una versin
implementada por la entidad receptora.
Si no es una versin implementada por la entidad receptora, el contador

(snmpInBadVersions) es incrementado y el paquete es descartado. En caso
57
afirmativo, se chequea la comunidad del mensaje para ver si se refiere a una conocida
a la entidad receptora.
Si la comunidad no es conocida, el contador (snmpInBadCommunityNames) es

incrementado y el paquete descartado. En caso afirmativo, se chequea la comunidad
para ver si esta tiene autorizacin para utilizar la operacin contenida en los datos del
mensaje.
Si no tuviera autorizacin, el contador (snmpInBadCommunityUses) es

incrementado y el paquete descartado. De otra forma, La entidad receptora chequea
para mirar que clase de recursos de objetos estn asociados con la comunidad
Si la comunidad se refiere a recursos de objetos locales, entonces la operacin se

desarrolla de acuerdo con los MIBs apropiados asociados con la comunidad.
En cambio si la comunidad se refiere a recursos de objetos remotos, entonces:
Si la operacin es una respuesta, entonces es correlativa con la anterior

peticin, y una respuesta es enviada a la entidad originaria de la peticin.
Si la operacin es una Trap o un informe, entonces el agente proxy, usando
conocimiento local, determina la entidad SNMP que debera enviar el mensaje.
De otra forma, La peticin se propaga por la relacin proxy definida por la
comunidad.
3.3 Esperando por mensajes
Normalmente las entidades SNMP esperan los mensajes en la direccin de

transporte por defecto asociada con cada dominio de transporte vlido para el.
Captulo 5: Modelo Operacional
Examinaremos el papel de las operaciones del protocolo en el entorno de

administracin. SNMP es un protocolo asncrono de peticin-respuesta basado en el
modelo de interrupcin-sondeo directo; esto significa que una entidad no necesita
esperar una respuesta despus de enviar un mensaje, por lo que puede enviar otros
mensajes o realizar otras actividades.
SNMP tiene pocos requisitos de transporte ya que usa un servicio de transporte no

orientado a conexin, y que normalmente es UDP. Aunque sto ratifica el Axioma
Fundamental, hay una razn ms importante: Las funciones de administracin de red
se realizan cuando hay problemas, de modo que la aplicacin de administracin es la
que decide qu restricciones realiza para el trafico de administracin. La eleccin de
un servicio de transporte no orientado a conexin permite a la estacin determinar el
nivel de retransmisin necesario para complacer a las redes congestionadas.
1. Interacciones del Protocolo
Una interaccin SNMP consiste en una peticin de algn tipo, seguida por una
respuesta. Hay cuatro resultados posibles de una operacin:
Una respuesta sin excepcin o error.

Una respuesta con una o ms excepciones.
58
Una respuesta con error.

Sobrepasar el tiempo de espera (timeout).
La definicin ASN.1 de una unidad de protocolo de datos SNMPv2 (ProtocolDataUnit)

es la siguiente:
PDUs ::=
CHOICE {
get-request
[0] IMPLICIT PDU,
get-next-request
[1] IMPLICIT PDU,
response
[2] IMPLICIT PDU,
set-request
[3] IMPLICIT PDU,
--[4] est obsoleta
get-bulk-request
[5] IMPLICIT PDU,
inform-request
[6] IMPLICIT PDU,
trap
[7] IMPLICIT PDU,
report
[8] IMPLICIT PDU
max-bindings
INTEGER ::= 2147483647

59
PDU ::=
SEQUENCE {
request-id Integer32,
error-status -- Algunas veces se ignora
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- Compatibilidad con proxy
badValue(3), -- Compatibilidad con proxy
readOnly(4), -- Compatibilidad con proxy
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnvailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
60
error-index -- Algunas veces se ignora
INTEGER (0..max-bindings),
variable-bindings -- A veces se ignoran los valores
VarBindList
-- colecciones de variables
VarBind ::=
SEQUENCE {
name
ObjectName,
CHOICE {
value ObjectSintax,
unspecified -- En peticiones de recuperacin
NULL,-- Excepciones en respuestas
noSuchObject[0]
IMPLICIT NULL,
noSuchInstance[1]
IMPLICIT NULL,
EndOfMivView[2]
IMPLICIT NULL
-- lista de instanciaciones de variables
VarBindList ::=
SEQUENCE(SIZE(0..max-bindings)) OF VarBind
61
En esta definicin se puede apreciar la influencia del Axioma Fundamental. Por

ejemplo, ni el campo error-status ni error-index se usan con el tipo de dato
GetRequest-PDU, pero al incluirlos, se puede usar un solo tipo de dato ASN.1 para el
intercambio de mensajes en todas las operaciones SNMPv2. Esto significa que slo
hay que escribir dos rutinas para codificar y decodificar los mensajes de la transmisin.
A continuacin se describen los campos del tipo de dato PDU.
request-id, valor entero usado por la aplicacin para distinguir entre peticiones
pendientes, lo que permite a la aplicacin mandar rpidamente varios
mensajes SNMP, reconocer mensajes duplicados en la red y medir el tiempo
del trfico que genera. Los agentes no pueden modificar este campo.
error-status, si no es cero, representa un error al procesar la peticin y que
debera ignorarse el campo variable-bindings.
error-index, si no es cero indica qu variable de la peticin es errnea.
variable-bindings, Lista de variables, con su nombre y valor.
Las operaciones de SNMPv2 se pueden clasificar as:
Recuperacin: get, get-next y get-bulk.

Modificacin: set.
Invocacin: snmpv2-trap.
Administradores: inform.
1.1 Interacciones
Veamos primero una interaccin normal entre dos entidades SNMPv2, para ms
adelante estudiar sus variaciones:
1. La entidad que inicia el protocolo hace una peticin con:
Un nico request-id.
error-status/error-index a cero.
Cero o ms instancias de variables.
2. Si la operacin no fue snmpv2-trap, la entidad que responde da una respuesta con:
El mismo request-id.
error-status a cero.
Las mismas instancias de variables.
Si se solicita una operacin de recuperacin, en la peticin, los valores asociados

con las variables tienen el valor unSpecified; si no, las instancias de variables
esperan valores. Si no se solicita una operacin de recuperacin, las instancias de las
variables de la respuesta son iguales a las de la peticin.
1.1.1 Interaccin de Excepciones

62
Mientras se procesa una peticin de recuperacin, el agente podra encontrar una

excepcin, indicando que una determinada variable no puede ser procesada. Hay tres
tipos de valores de excepcin:
noSuchObject, indica que el tipo de objeto correspondiente a la variable no se

implementa por el agente.
noSuchInstance, indica que la instancia de un objeto particular identificado por
la variable no existe en la vista del MIB para la operacin.
endOfMibView, indica que no hay ms informacin en la vista del MIB para la
operacin.
Por tanto, el funcionamiento de interacciones SNMPv2 con excepciones es de la

siguiente forma:
1. La entidad que inicia el protocolo hace una peticin de recuperacin con:
Un nico request-id.
2. La entidad que responde da una respuesta con:
Las mismas instancias de variables, pero con diferentes valores y uno o ms
valores de excepcin.
1.1.2 Interaccin de Error
Mientras se procesa alguna peticin, el agente puede encontrar un error e indica que
la operacin no puede procesarse. Hay varias clases de error. El funcionamiento de
interacciones SNMPv2 con excepciones es de la siguiente forma:
1. La entidad que inicia el protocolo hace una peticin de recuperacin con:
Un nico request-id.
2. La entidad que responde da una respuesta con:
Las mismas instancias de variables que la peticin.
Teniendo en cuenta que los errores nunca se devuelven en una respuesta a una
operacin de invocacin, hay dos clases de errores que pueden devolverse en la
respuesta a cualquier otra peticin:
tooBig, indica que la respuesta podra ser demasiado larga para enviarla.
genErr, no debera devolverse excepto que no haya otra posibilidad.
63
Si se procesa una peticin de modificacin, hay otra case de errores que deberan
devolverse, pero que se vern ms adelante.
1.1.3 Interaccin de Timeout
Esta interaccin ocurre cuando se enva una peticin, pero no se recibe respuesta.
Hay varias posibilidades:
La red omite la peticin.

El agente no est ejecutndose.
El agente omite la peticin.
La red omite la respuesta.
El tiempo de espera fue muy corto.
1.1.4 De la Interaccin al Procesamiento
Para procesar las peticiones, primero debe aceptarse una estructura Message para
que la evale la entidad. Cuando la peticin se procesa, se examina la lista de
variables instanciadas; en el caso que el campo variable-bindings est vaco, termina
el procesamiento devolviendo una respuesta noError.
1.2 Peticiones de Recuperacin
Para examinar eficientemente la informacin de administracin, el entorno de

administracin usa un mtodo inteligente para identificar las instancias: Es usado un
OBJECT IDENTIFIER, formado por la concatenacin del nombre del tipo objeto con
un sufijo.
1.2.1 El Operador Get
Si la aplicacin de administracin conoce las instancias que necesita, realiza una

get-request. Slo se pueden devolver los errores tooBig y genErr.
Por otro lado, para cada variable de la peticin, la instancia se recupera de la vista
del MIB con esta operacin:
Si el agente no implementa el tipo objeto asociado con la variable, se devuelve

la excepcin noSuchObject.
Si la instancia no existe o no la soporta el MIB, se devuelve la excepcin
noSuchInstance.
Se devuelve el valor asociado a la instancia.
1.2.2 El Operador Get-Next
Si la aplicacin no conoce exactamente la instancia de la informacin que necesita,

realiza una get-next-request. Slo se pueden devolver los errores tooBig y genErr.
Por otro lado, para cada variable de la peticin, se devuelve la primera instancia que
siga a la variable que est en la vista del MIB con esta operacin:
Si no hay una prxima instancia para la variable en el MIB, se devuelve una

excepcin endOfMibView.
64
Si se reconoce la siguiente instancia de la variable en el MIB, se devuelve el

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

agente.
Debido al almacenamiento que se hace en el MIB, las tablas se examinan en un

orden columna-fila; as, se examina cada instancia de la primera columna, cada
instancia de la segunda y as seguidamente hasta el final de la tabla. Entonces, se
devuelve la instancia del siguiente objeto , y slo se devuelve una excepcin si el
operando de get-next es mayor, lexicogrficamente hablando, que la mayor instancia
del MIB.
Como el operador get-next soporta mltiples operandos, se puede examinar

eficientemente la tabla entera. La aplicacin de administracin conoce que llega al final
de la tabla cuando se devuelve un nombre cuyo prefijo no coincide con el del objeto
deseado.
Puede ocurrir que al usar el operador get-next con mltiples operandos para
examinar una tabla vaca, se devuelva un error de tipo tooBig en vez de devolver las
mltiples instancias de la variable. Esto ocurre debido a que el operador no pudo
encontrar instancias en la tabla.
1.2.3 El Operador Get-Bulk
Su funcin es minimizar las interacciones en la red, permitiendo al agente devolver

paquetes grandes. Este esquema tiene que funcionar con un servicio de transporte no
orientado a conexin de modo que la aplicacin sea la responsable de controlar las
interacciones. Las aplicaciones de administracin tambin deben controlar los tiempos
de las interacciones
El formato que sigue la SNMPv2 BulkPDU es el siguiente:
BulkPDU ::=
SEQUENCE {
request-id Integer32,
non-repeaters INTEGER(0..max-bindings),
max-repetitions INTEGER(0..max-bindings),
variable-bindings VarBindingList
Este formato es estructuralmente idntico la del resto de operaciones SNMP, y los

campos se describen a continuacin:
request-id, el usual.
65
non-repeaters, nmero de variables que deberan recuperarse de una vez.

max-repetitions, nmero mximo de veces que otras variables deberan
recuperarse.
variable-bindings, el usual ignorando los valores.
Cuando un agente recibe una get-bulk, calcula el mnimo de:
El tamao mximo del mensaje del emisor.

El tamao de la generacin de mensajes del propio agente.
De aqu resta la suma de dos cantidades:
El tamao de las capas de privacidad/autentificacin de la generacin de la

respuesta.
El tamao de una respuesta sin variables instanciadas.
Dicha diferencia indica la cantidad mxima de espacio posible para las instancias de
las variables en la respuesta. Si la diferencia es menor de cero, la respuesta se pierde;
si no, se genera la respuesta, que tendr cero o ms variables instanciadas.
El agente examina las variables de la peticin usando el operador get-next y

aadiendo cada nueva instancia con su valor a la respuesta y decrementando la
cantidad de espacio libre. Si no hay suficiente espacio, se enva la respuesta antes de
colapsar el espacio libre.
Finalmente, el espacio libre se ocupa, o se realiza el mximo nmero de

repeticiones. Es importante tener en cuenta que el agente puede terminar una
repeticin en cualquier momento.
Existe otra forma con la que la operacin get-bulk termina prematuramente: Esto
ocurre cuando al examinar las variables de la tabla, se devuelve una excepcin
endOfMibView. En este caso, todas las futuras repeticiones devolvern lo mismo y se
omitirn de la respuesta.
Por ltimo, es importante saber que cuando un agente decide procesar una peticin
get-bulk, slo se puede devolver el error genErr, ya que devolver tooBig no tiene
sentido.
1.2.4 Ms Caractersticas del Operador Get-Bulk
La respuesta a un operador get-bulk no es ms que la concatenacin de un nmero

de respuestas max-repitition de interacciones get-next.
La parte ms interesante del operador get-bulk es que puede implementarse en el

agente a alto nivel mejor que en las rutinas especficas de los objetos.
1.3 Peticiones de Modificacin
Slo hay una peticin de modificacin: El operador set. Cuando una aplicacin de
administracin conoce exactamente las instancias que necesita, genera una set-
request.
La semntica de la operacin set es tal que la operacin tiene xito si y slo si todas
66
las variables se actualizan. Para explicarlo usaremos el concepto del compromiso de

las dos fases, pero antes de empezar, se asegura que la respuesta no sea tan grande
como para no poder ser enviada, ya que si no, se generara un error tooBig.
Dicho concepto consta de dos pasadas. En la primera, cada instancia se examina y

se hace una comprobacin para verificar que:
La variable es soportada por la vista del MIB para esa operacin.

Si la variable existe, el agente puede modificar las instancias del tipo objeto
correspondiente.
El valor proporcionado es correcto sintcticamente.
Si la variable no existe, el agente es capaz de crear instancias del tipo de
objeto correspondiente.
El nombre y valor proporcionado son correctos sintcticamente y son
consistentes con los valores de las otras variables de la peticin.
Todos los recursos necesarios para el cambio estn reservados.
Si alguna de estas condiciones no se verifica para alguna de las instancias, se

devuelve el error apropiado y se liberan los recursos.
SNMPv2 soporta nuevos cdigos de error, adems de los habituales, que son los
siguientes, as como las causas que los producen:
noAccess, la variable no es soportada por la vista del MIB para esa operacin.
notWritable, La variable existe pero el agente no puede modificar instancias
del tipo objeto correspondiente.
wrongType, el nuevo valor proporcionado es de un tipo de datos ASN.1
errneo.
wrongLength, el nuevo valor proporcionado es de longitud errnea.
wrongEncoding, el nuevo valor proporcionado est codificado errneamente.
wrongValue, el nuevo valor est fuera del rango de valores admitidos para el
tipo de objeto correspondiente.
noCreation, la variable no existe y el agente no puede crear instancias del tipo
objeto correspondiente.
inconsistentName, la variable no existe y no puede ser creada porque el
nombre de la instancia es inconsistente con los valores de otro objeto en el
agente.
inconsistentValue, el valor proporcionado es inconsistente con los valores de
otro objeto en el agente.
resourceUnvailable, un recurso requerido no puede ser reservado.
Los cdigos noCreation y notWritable son de tipo permanente, mientras que los
tres ltimos son de tipo transitorio. El resto son casos que no deberan ocurrir si la
aplicacin y el agente tuvieran un mismo concepto de los objetos en cuestin.
Slo si cada instancias 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:
commitFailed, indica que hubo un fallo en la segunda pasada pero que se

deshicieron los cambios.
67
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.
1.3.1 Ms Caractersticas del Operador Set
Cuando una aplicacin de administracin usa la operacin set, hay que tener en
cuenta varias cosas:
Hay que tener cuidado al agrupar objetos en una sola peticin set, ya que si
algn objeto puede resetear al agente, el resto de objetos no tendrn ningn
efecto.
El servicio de transporte puede duplicar peticiones o repartir peticiones que
estn fuera de servicio. Por tanto, si una operacin set depende de otra
operacin set anterior, la segunda debe esperar hasta que los paquetes de la
primera peticin no existan en la red. Esto se puede solucionar con la
convencin textual TestAndIncr., o incluir snmpSetSerialNo en el set para
asegurar el procesamiento ordenado de las peticiones.
Para algunos objetos no debera retransmitirse la operacin set slo porque no
se haya obtenido respuesta y sin usar una operacin get para asegurarse que
la operacin set tuvo efecto.
1.4 Manejo de Filas de Conceptos
Desde la perspectiva del protocolo, no existe el concepto de fila en SNMP. En

particular no existe relacin entre las variables presentadas en una lista de variables.
Cualquier relacin existe como una caracterstica del diseo de MIB, no por
operaciones de protocolo.
Podemos considerar un reto el crear instancias en una fila de conceptos, dado el

modelo operacional que usa el entorno de administracin. Hay que tener en cuenta:
El agente puede no ser capaz de implementar algunas columnas en una fila de

conceptos.
El agente puede necesitar que algunas columnas se creen antes de usarlas.
Los valores de todas las columnas pueden no entrar en una sola PDU.
La aplicacin de administracin puede querer examinar los valores de algunas
columnas.
Las aplicaciones que cooperan no quieren comisionar al crear nuevas filas.
En SNMPv2, la convencin textual RowStatus se usa para expresar la forma de

manipular una fila: cuando una tabla se define en un mdulo MIB, debe definirse una
columna status con la sintaxis de RowStatus. El significado de una variable de la
columna status es que su valor indica la relacin entre el dispositivo y la fila de
conceptos.
Un resumen de la convencin textual RowStatus es la siguiente:
RowStatus ::= TEXTUAL-CONVENTION

68
...
SYNTAX INTEGER {
--dos valores de estado/accin que pueden ser leidos o escritos.
active(1),
notInService(2),
--un valor de estado, que solo puede ser ledo.
notReady(3),
--tres valores de accin que slo pueden ser escritos
createAndGo(4),
createAndWait(5),
destroy(6)
1.4.1 Creacin de una Fila de Conceptos
El primer paso es la creacin de un identificador de la instancia, que es especfico

para cada tabla MIB. El identificador de instancia debe tener sentido semnticamente
o ser usado singularmente. En el ltimo caso, el mdulo MIB puede proporcionar un
objeto para ayudar a elegir un identificador sin usar, aunque si dos aplicaciones eligen
el mismo identificador, la convencin RowStatus genera un mecanismo para evitar la
colisin.
El siguiente paso es crear la fila, y se puede hacer de dos formas:
Aproximacin Directa, la fila se crea y se activa para ser usada por un

dispositivo con una sola operacin set.
Aproximacin Negociada, se crea la fila y por medio de un conjunto de
interacciones, se inicializa y se activa para ser utilizada por el dispositivo.
La aplicacin de administracin debe determinar para cada columna:
Qu columnas necesita el agente para activar la fila.

Qu columnas no puede crear el agente, por alguna razn.
Una vez creada la fila, la aplicacin realiza una operacin get para cada columna
que conoce, usando el identificador seleccionado en el primer paso. Para cada
columna requerida:
69
Si se devuelve un valor, el agente est indicando que implementa esa columna.

Si se devuelve una excepcin noSuchInstance, el agente indica que
implementa la columna, pero que la instancia en s no existe.
Si se devuelve una excepcin noSuchObject, el agente indica que no
implementa el tipo de objeto correspondiente a esa columna.
1.4.1.1 Aproximacin Directa
Primero se selecciona el identificador deseado. Entonces la aplicacin decide lanzar

un get para determinar los requisitos del agente para la columna. Todos los valores
devueltos deberan ser excepcionales, ya que si no se indicara que la fila ya existe.
Entonces la aplicacin enviar al agente un set, que contiene valores para las
columnas con un MAX-ACCESS de read-create y el estado de la columna puesto a
createAndGo.
Cuando el agente procesa la columna de estados en las instancias, si la variable ya

existe, devuelve un error inconsistentValue; si no, el agente comprueba que tiene
suficiente informacin (procedente del set y de informacin local) para crear y activar
la fila. Si hay suficiente informacin, entonces:
Se crea la fila.
Se devuelve una respuesta con noError
El agente asigna valores por defecto a las columnas de las filas cuyos valores
no se especificaron en el set.
La columna de estado se pone a active.
Si no hay suficiente informacin, se devuelve un error inconsistentValue.
Se debera tener en cuenta que puede que no todas las filas entren en una sola
PDU. Tambin, la respuesta de get indica que aquellas columnas que implemente el
agente deben ser superconjuntos de las columnas que son obligatorias. As, en el set,
la aplicacin slo tiene que preocuparse de las columnas con un MAX-ACCESS de
read-create.
Para que esta aproximacin funcione, la versin del mdulo MIB que conoce la
aplicacin y el agente debe coincidir.
1.4.1.2 Aproximacin Negociada
Lo primero es seleccionar el identificador deseado. Entonces, la aplicacin genera

un set con la columna de estado puesta a createAndWait y lo enva al agente.
Cuando el agente procesa la columna de estado en las instancias, si no soporta la
creacin negociada, devuelve un error wrongValue, o si la variable ya existe, devuelve
un error inconsistentValue. En otro caso:
Se crea la fila.
Se devuelve una respuesta noError.
El agente asigna valores por defecto a las columnas de las filas cuyos valores
no se especificaron en el set.
El agente debe asignar valores por defecto a aquellas filas que implementa de
70
solo lectura.
La columna de estado se activa a notInService o a notReady, segn la
informacin disponible del agente.
La estacin de administracin puede usar entonces un get para determinar los

requisitos de las columnas del agente. Para cada columna read-create solicitada:
Si se devuelve un valor, el agente indica que implementa esa columna y que si

a la aplicacin no le gusta el valor, debe generar un set para cambiarlo.
Si se devuelve una excepcin noSuchInstance, el agente indica que antes de
activar la fila, la aplicacin debe generar un set para proporcionar valores para
la columna.
Si se devuelve una excepcin noSuchObject, el agente indica que la
aplicacin no debe intentar dar un valor.
Cuando el valor de una columna de estado cambia a notInService, el agente indica

que la fila est siendo usada en el dispositivo y que la aplicacin debera poner la
columna de estado a activa. Hay que tener en cuenta que es la aplicacin la que
determina el nmero de operaciones set que quiere realizar.
Si una fila se encuentra en el estado notInService o notReady, pueden aparecer

problemas: Si el dispositivo crea o modifica la misma fila que est siendo negociada
entre la aplicacin y el agente, entonces existirn dos copias, una en el dispositivo y
otra en el agente, aunque cuando la columna de estado se active en el agente, sta
eliminar la del dispositivo.
Tambin puede ocurrir que el proceso de negociacin se vea interrumpido. Por eso, el
agente debe almacenar de vez en cuando filas que no estn en estado activo.
1.4.2 Modificacin de una Fila de Conceptos
Algunos mdulos MIB precisan que se desactive una fila para poder modificarla.
Para ello, la aplicacin pone la columna de estado a notInService. Si el agente no lo
soporta, devuelve un error wrongValue; si no, la fila no es accesible para el dispositivo
y se devuelve una respuesta de noError.
Desactivar una fila es til cuando las modificaciones no caben en una sola PDU. Por
supuesto, hasta que no se hacen todas las modificaciones, la fila no ser consistente,
por lo que el agente pone la columna de estado a notReady.
1.4.3 Eliminacin de una Fila de Conceptos
La aplicacin pone la columna de estado a destroy. El agente hace la fila

inaccesible al dispositivo y a l mismo y devuelve una respuesta noError.
1.5 Interacciones de Invocacin
Cuando un agente detecta un evento extraordinario, se genera una invocacin

snmpV2-trap, que se enva a una o ms aplicaciones de administracin. La
invocacin snmpV2-trap tiene un formato idntico a las PDU usadas en otras
peticiones.
Las dos primeras instancias son especiales:

71
sysUpTime.0, momento en que se gener la invocacin.

snmpTrapOID.0, el identificador de objeto de la invocacin.
1.5.1 El Grupo snmpTrap
Hay dos objetos escalares relacionados con las invocaciones SNMP.
snmpTrap OBJECT IDENTIFIER ::={snmpMIBObjects 4}
snmpTrapOID OBJECT-TYPE
MAX-ACCESS accesible-for-notify
...
::= {snmpTrap 1}
1.6 Interacciones entre Administradores
Cuando una aplicacin quiere informar a otra aplicacin, genera una inform-
request. El formato de la InformRequest-PDU es idntico al de las otras PDU del
resto de peticiones. Al igual que snmpV2-trap, las dos primeras instancias indican el
momento del evento y su identidad.
Como es de esperar, slo algunos dispositivos pueden tener el papel de

administrador. Hay que tener cuidado para minimizar el nmero de informes que se
generan. Actualmente, el control de la generacin y retransmisin de informes es una
tarea especfica de implementacin.
1.6.1 Entidades de Doble Rol
Se trata de dispositivos que contienen agentes y aplicaciones de administracin.

Estos dispositivos recogen y procesan informacin de los agentes y la proporcionan a
los administracin. As, segn el entorno SNMPv2, una aplicacin de administracin es
algo que inicia una interaccin entre peticiones y respuestas.
Quin Genera Recibe
Agente Response, snmpV2-trap Get, get-next, get-bulk,

set
72
Administrador Get, get-next, get-bulk, Response, snmpV2-trap,

set, inform, response inform
2. Mapeo de Transporte
Las operaciones SNMP son independientes del protocolo de transporte, utilizando

slo un servicio de transporte no orientado a conexin.
Para definir el mapeo de transporte, se especifican dos pasos:
Reglas para tomar la estructura de un mensaje y transformarlo en una cadena

de octetos para formar un paquete.
Reglas para enviar el paquete por el servicio de transporte.
Hay varios mapeos de transportes definidos y usan el mismo conjunto de reglas para
el primer paso. Como todos los objetos y estructuras SNMP se definen con el ASN.1
de OSI, el entorno de administracin usa BER (Basic Encoding Rules) de OSI para
codificar las estructuras en octetos. Cuando stos se reciben, se transforman en una
estructura de datos con una semntica idntica.
2.1 Direcciones y Dominios de Transporte
La relacin del protocolo de administracin y el servicio de transporte se denomina

Dominio de Transporte.
2.1.1 Dominio snmpUDPDomain
Identifica el uso de SNMPv2 sobre UDP. Este es el mapeo preferido.
Si un objeto TDomain tiene un valor de snmpUDPDomain, entonces el

correspondiente objeto TAddress se codifica en seis octetos:
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
Octetos Contenido Codificacin
1..4 Direccin IP Network-byte order

73
5..6 Puerto UDP Network-byte order
SYNTAX OCTET STRING (SIZE (6))
La entidad que enva transforma y enva el mensaje como un nico datagrama UDP
a la direccin de transporte de la entidad receptora. Por convencin, los agentes
SNMP escuchan en el puerto UDP 161 y envan las notificaciones al puerto UDP 162,
aunque una entidad debera configurarse para usar cualquier selector de transporte
aceptable.
Todas las entidades receptoras deben admitir mensajes de al menos 1472 octetos
de longitud.
2.1.2 Dominios snmpCLNSDomain y snmpCONSDomain
Identifican el uso de SNMPv2 en los servicios de transporte no orientados a

conexin de OSI (CLTS): snmpCLNSDomain se usa cuando CLTS se ejecuta en
servicios de red no orientados a conexin de OSI (CLNS), mientras que
snmpCONSDomain se usa cuando CLTS se ejecuta en servicios de red orientados a
conexin de OSI (CONS).
Si un objeto TDomain tiene alguno de estos dos valores, el correspondiente objeto

TAddress se codifica as:
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
1 Longitud de NSAP N como un entero sin signo
(0 de 3 a 20)
2..(n+1) NSAP Representacin binaria concreta
(n+2)..m TSEL Cadena de hasta 64 octetos

74
SYNTAX OCTET STRING (SIZE (1 | 4..85))
La entidad que enva transforma el mensaje y lo enva como una nica unidad de
datos del servicio de transporte (TSDU) a la direccin de transporte de la entidad
receptora. Los selectores de transporte por defecto son:
Mapeo Entidad Selector
CLTS sobre CLNS Agente Snmp-l
CLTS sobre CLNS Notificaciones Snmpt-l
CLTS sobre CONS Agente Snmp-o
CLTS sobre CONS Notificaciones Snmpt-o
Una entidad debera poder configurarse para usar cualquier selector de transporte
aceptable. Todas las entidades receptoras deben admitir mensajes de al menos 1472
octetos de longitud.
2.1.3 Dominio snmpDDPDomain
Identifica el uso de SNMPv2 sobre Appletalks DDP.
Si un objeto TDomain tiene un valor de snmpDDPDomain, entonces el

correspondiente objeto TAddress se codifica as:
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
1 Longitud del objeto Entero sin signo

75
2..(n+1) Objeto Cadena de hasta 32 octetos
(n+2) Longitud de tipo Entero sin signo
(n+3)..(n+2+p) Tipo Cadena de hasta 32 octetos
(n+3+p) Longitud de zona Entero sin signo
(n+4+p)..(n+3+p+q) Zona Cadena de hasta 32 octetos
SYNTAX OCTET STRING (SIZE (3..99))
La entidad que enva transforma el mensaje y lo enva como un nico datagrama

DDP a la direccin de transporte de la entidad receptora. Todos los agentes SNMP
escuchan en el tipo NBP SNMP Agent y las notificaciones se envan al tipo NBP
SNMP Trap Handler. Todas las entidades receptoras deben admitir mensajes de al
menos 484 octetos de longitud.
2.1.4 Dominio snmpIPXDomain
Identifica el uso de SNMPv2 sobre NetWares IPX
Si un objeto TDomain tiene un valor de snmpIPXDomain, entonces el

correspondiente objeto TAddress se codifica as:
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
1..4 Nmero de red Network-byte order

76
5..10 Direccin fsica Network-byte order
11..12 Nmero de socket Network-byte order
SYNTAX OCTET STRING (SIZE (12))
La entidad que enva transforma y enva el mensaje como un nico datagrama IPX a
la direccin de transporte de la entidad receptora. Por convencin, los agentes SNMP
escuchan en el socket IPX 36879 y envan las notificaciones al socket IPX 36880,
aunque una entidad debera configurarse para usar cualquier selector de transporte
aceptable.
Todas las entidades receptoras deben admitir mensajes de al menos 546 octetos de
longitud.
3. Resumen
SNMP es un protocolo Asincrono de Peticin-Respuesta basado en el modelo de

interrupcin-Sondeo Directo.
Necesita pocos requisitos de la capa de transporte (No orientada a conexin UDP)
En la interaccin SNMP se producen peticiones seguidas de respuestas; se pueden

producir 4 clases distintas de resultados:
Resultado correcto
Timeout
1 o varias Excepciones
Error
Existen 4 posibles tipos de operaciones:
Recuperacin:GET(conoce exactamente la instancia que necesita), GET-

NEXT(no la conoce) y GET-BULK (reduce la interacin en la red al usar
77
paquetes mas grandes).
Modificacin:SET.
Invocacin: SNMPV2-TRAP.
Administracin: INFORM.
Las operaciones SNMP son independientes del protocolo de transporte usado, pero
utilizaremos solo un servicio de transporte no orientado a conexin.
Usaremos reglas para: formar el paquete y el envio del paquete.
Llamamos Dominio de Transporte a la relacin del protocolo de administracin con el

servicio de transporte:
SnmpUDPDomain. Snmp sobre UDP
SnmpCLNS/CONSDomain. No orientado a conexin / Orientado a conexin
SnmpDDPDomain. Snmp sobre Appletalk's DDP
SnmpIPXDomain. Snmp sobre Netware IPX.
Un sistema SNMP viene determinado por todos aquellos datos que es capaz de
procesar, es decir, el fundamento de la gestin de una red sern todas aquellas
estructuras que se encarguen de almacenar los datos que se gestionarn en el
sistema. Posteriormente una aplicacin SNMP, ejecutndose sobre un administrador
de dicho protocolo, ser la encargada de visualizar parte o la totalidad de los datos
que son soportados por dichas estructuras.
Es claro que una aplicacin SNMP no podr dar informacin sobre datos que no estn
almacenados en alguna variable, por lo que en esto difieren la mayora de los mdulos
MIB que existen en los distintos sistemas de gestin de red existentes en el mercado.
Este mdulo, como se puede ver de forma ms amplia en la documentacin adjunta,
ser el encargado de almacenar estas y otras estructuras que harn falta para
justificar la vala de los datos. Por ejemplo, de qu nos servira un valor de bytes
transmitidos si no sabemos cundo fue la ltima vez que se ley ese dato?, o quin
fue la fuente de esos bytes transmitidos?...
78
CMO FUNCIONA?
A continuacin se muestra el contenido de un mdulo MIB genrico de un agente

SNMP al cual se le pueden incluir unas determinadas estructuras, seleccionando la
opcin adecuada, que almacenarn los valores que se indiquen, los cuales permitirn
al administrador obtener datos sobre el trfico existente en la red. El funcionamiento
del sistema se basa en simular lo que hara o podra hacer una aplicacin SNMP sobre
una agente SNMP, el cual puede tener las estructuras que abajo se indican;
Datagramas UDP: Nmero total de datagramas UDP que discurren por la red.
Segmentos TCP: Nmero total de segmentos TCP transmitidos en la subred.
Datagramas UDP fragmentados: Indica cuantos de los datagramas UDP que

circulan por la red, han debido ser fragmentados por superar 1514 bytes.
Segmentos TCP fragmentados: Cuantos segmentos TCP han sido

particionados por superar el lmite de tamao de los paquetes del protocolo.
Bytes transmitidos sobre TCP: Total de bytes transmitidos en paquetes TCP

(Incluye cabeceras, etc.)
Bytes transmitidos sobre UDP: Suma total de los bytes de los paquetes UDP.
Trfico interno/externo: Porcentaje de trfico que es interno/externo a la

subred.
Una vez pulsado el botn "Generar el mdulo MIB", se generar el mdulo MIB
genrico con las estructuras adecuadas, y aparecer un botn para realizar la
"Simulacin". Una vez pulsado ste ltimo, aparecer un pequeo cuadro de
configuracin del nmero de sistemas servidores y clientes disponibles en la red, as
como la franja horaria y el tiempo total de simulacin. Por ltimo, el botn "Realizar
simulacin", mostrar el resultado de la simulacin en unas grficas.
Tambin se incluye un glosario sobre las estructuras de datos ms relevantes del

mdulo MIB.
Manual de usuario
Introduccin
El motivo fundamental de este documento es el esclarecimiento de las operaciones

realizables con la parte ejecutable del proyecto, la cual se basa, a groso modo, en la
realizacin de un modelo de simulacin que nos permita conocer ms a fondo las
79
posibilidades de un sistema que disponga de uno o ms agentes SNMP y varios

clientes.
En esta parte no nos centraremos en el por qu de los datos que se pueden

visualizar, ni tampoco en los fundamentos tericos que motivan un comportamiento u
otro por parte del programa, ya que de esto se explica convenientemente en otro
documento.
Se ha de recordar antes de comenzar la explicacin que la pgina html que posee la

parte que incluye la simulacin es la titulada "Mdulo MIB"
Variables a incluir
Es imprescindible incluir una serie de estructuras o tipos, de los cuales se

crearn instancias de variables, y que almacenarn los valores de los estadsticos que
se desee tener en cuenta. En este caso, se han incluido ocho estadsticos, que
pueden ser pulsados con el ratn para ser seleccionados:
(figura 1)
La pulsacin de cualquiera de ellos se tendr en cuenta a la hora de generar el mdulo

MIB adecuado.
Significado de las variables:

80
Datagramas UDP transmitidos y Segmentos TCP transmitidos: Ambas

indican que se ha de tener en cuenta, en el mdulo MIB, y en la supuesta
aplicacin SNMP, el nmero de datagramas y segmentos que se transmiten por
la red y cuyo protocolo de transporte es el UDP y TCP respectivamente. Al ser
un nmero de paquetes, parece lgico que la estructura de datos que le
contendr sea de tipo Counter, es decir un contador que incrementar el cliente
SNMP cuando enve un paquete por la red.
Datagramas UDP fragmentados y Segmentos TCP fragmentados: Estas
variables tendrn en cuenta el nmero de paquetes que se envan bajo el
protocolo de transporte UDP y TCP respectivamente, los cuales, por ser de
longitud mayor de la permitida por el protocolo (1514 bytes), han sido
fragmentados en varios paquetes de transporte.
Bytes transmitidos sobre TCP y sobre UDP: Se usarn para tener en cuenta
el total de bytes transmitidos por la red, que iban en paquetes de transporte
TCP y UDP respectivamente.
Trfico interno y externo: Nmero de bytes que han circulado por la red y
cuyo destino era un sistema (Estacion de trabajo, servidor de red, PC, etc...),
perteneciente o no, segn si hablamos del interno o el externo, a la subred.
Esto se puede observar comparando la direccin IP origen y destino con la
mscara de la subred, que en este caso es la "150.214.69".
Generando el mdulo MIB
Una vez que conocemos el significado de los posibles estadsticos a incluir, no

queda ms que pulsar el botn que indica "Pulse para generar el mdulo MIB". Una
vez hecho esto, aparece, por debajo del botn, un ttulo y una ventana de texto, que
muestra el mdulo MIB genrico que podra contener cualquiera de los clientes SNMP
que formaran parte de la red con las estructuras de datos necesarias y en notacin
ASN.1, la cual est convenientemente explicada en otra seccin de la documentacin.
81
(figura 2)
Todas las estructuras que contiene el mdulo MIB son altamente autoexplicativas, ya
que todas ellas contienen una clusula "DESCRIPTION", la cual contiene una cadena
de caracteres que explica la funcionalidad de la estructura que la contiene.
Tambin se puede observar la presencia, en la parte inferior de la figura 2, de otro

botn que nos da paso a la simulacin.
Opciones de simulacin
Una vez que se ha incidido con el "click" del ratn sobre el botn de
"Simulacin", aparecen una serie de posibles selecciones sobre el sistema a simular:
82
(figura 3)
En esta parte de la configuracin, se determinar el nmero de sistemas

servidores y clientes que componen la subred. Aunque un sistema real se compondr
de bastantes ms servidores y clientes, se ha limitado, para la simulacin, a 25
equipos de cada tipo, siendo los servidores, aquellos equipos que poseen un HD y
programas que son usados por el resto de servidores y clientes.
Otra de las opciones configurables del modelo de simulacin es la franja horaria a

simular y el nmero de horas de la simulacin:
Maana : Se supone entre las 6:00 y las 14:00 horas.

Tarde: Entre las 14:00 y las 22:00 horas.
Noche: Entre las 22:00 y las 6:00 horas.
Existe una ltima opcin que es la de "Acumular datos anteriores" que una vez
pulsada, nos permitir ver la evolucin de los datos a lo largo de varias simulaciones.
Ejemplo: Si queremos ver el trfico de todo un da no tenemos ms que realizar tres
simulaciones, de ocho horas, con esta opcin pulsada. Hay que sealar que los datos
muestran los valores acumulados de una marca horaria con su homloga de la
siguiente simulacin, lo cual no ofrece un dato especialmente significativo, pero si
muestra el volumen total de trfico a lo largo de las simulaciones acumuladas.
Resultados de la simulacin
Los resultados de la simulacin emulan o intentan emular a lo que sera una

aplicacin SNMP ejecutndose sobre un agente SNMP, es decir, una aplicacin que,
cada cierto tiempo, lee los valores de las variables de los clientes SNMP, y realiza una
representacin por pantalla de los mismos. La representacin podra ser a base de
datos numricos o en formato grfico, siendo ste ltimo, el optado para la muestra
por pantalla de los valores obtenidos de la simulacin, ya que permite una percepcin
83
global mucho ms rpida y precisa, y al no ser un sistema real, la visualizacin de

valores concretos sera poco menos que desmerecer el trabajo realizado.
(figura 4)
En la figura 4 podemos observar el resultado obtenido tras pulsar el botn de

"Realizar simulacin" con ciertas opciones de simulacin qu ms da- y habiendo
seleccionado todas las variables opcionales en el MIB.
El resultado siempre sern 5 grficos que representarn el nmero de paquetes por

tiempo, el porcentaje de trfico por tiempo y los Mb por tiempo, en el caso de los tres
superiores llamados generales; y el nmero de paquetes TCP y UDP por tiempo para
uno de los servidores y uno de los clientes, en el caso de los inferiores.
La aparicin del nmero de componentes de cada grfica depender de las variables

del MIB seleccionadas en el momento de su generacin.
La componente X de las escalas, es bastante explcita por el contenido de la grfica

y su ttulo. Hay que notar que las escalas de paquetes y Mbytes son variables, y que
no siempre, la misma altura, representa el mismo valor.
La componente Y de las escalas, se puede ver que es la misma en las 5 grficas y

una sexta parte del tiempo total de simulacin, es decir, si se toman 6 horas, cada
intervalo, que representa cada cuanto tiempo se recogen los valores de los clientes y
se realiza la representacin, ser de 1 hora.
Conclusiones
84
Este sistema ofrece una visin global de lo que podra ser un sistema SNMP, pero
nunca hay que olvidar que est basado en el trfico total de una subred durante un da
completo, es decir, no se pueden establecer conclusiones generales sobre los
resultados o interpolarlas a otro sistema que disponga de otras aplicaciones y otros
horarios de trabajo.
La aplicacin ofrece alta interactividad del usuario, y es por esto que permite realizar
muchos tipos de simulaciones que pueden ofrecer ideas claras sobre un sistema, pero
al mismo tiempo, un uso inconsciente de la misma, puede ofrecer datos que en
absoluto tengan relacin con un sistema real.
Fundamentos de la simulacin
La simulacin se basa en recrear unos datos reales, en este caso del trfico de una
subred real.
Se han tomado los datos del nmero de paquetes UDP y TCP de un sistema real,
junto con el tamao de dichos paquetes y su direccin origen y destino, durante todo
un da. Dichos valores han sido luego procesados para separar los paquetes
generados por sistemas servidores, siendo estos los que poseen un disco duro y
aplicaciones compartidas para el resto de usuarios del sistema; y los generados por
sistemas clientes, es decir, que hacen uso de las aplicaciones que se encuentran los
servidores.
Una vez separados estos datos, se obtuvieron estadsticos para el nmero de

paquetes UDP y TCP, es decir, la media y varianza de paquetes que genera cada
sistema (por un lado, los clientes y por otro los servidores). Tambin se extrajeron
dichos estadsticos para obtener el tamao medio de dichos paquetes, la fraccin de
los mismos que ocupan ms de 1514 bytes (fragmentados), y en qu proporcin, su
destinatario es un sistema no perteneciente a la subred.
Hay que hacer notar que se obtuvieron tres juegos de los estadsticos anteriormente
mencionados: uno para el trfico generado durante la maana, otro para el de por la
tarde, y un ltimo para el trfico nocturno.
La aplicacin (applet) que realiza la simulacin contiene los valores de los

estadsticos obtenidos con el procedimiento anterior, y, haciendo uso de una funcin
que genera valores para una distribucin normal (0,1) media 0 y desviacin tpica 1
recrea uno a uno los sistemas que componen la simulacin, es decir, si ha de generar
3 servidores, para obtener su nmero de paquetes TCP hara:
N de paquetes TCP de servidor0= MTCPServ DtcpServ * Normal(0,1)
Siendo:
MTCPServ, el nmero medio de segmentos TCP que genera un sistema servidor
DtcpServ, la desviacin tpica de paquetes generados por un servidor.

85
Adems, dicho valor es recalculado para la siguiente franja horaria, es decir, al existir
6 fracciones del tiempo total seleccionado, se calcula el valor de todos los estadsticos
de todos los equipos de la subred 6 veces en una simulacin completa.
El resto de valores se calculan de la misma forma, escalando las grficas de forma

pertinente procurando que los valores no superen el lmite superior de la misma.
Bibliografa
Brogden, Tittel - Manual fundamental de Java - Ed. Anaya Multimedia - 1997

Garca Aparicio, Enrique - Enciclopedia de Excel 5 para Windows. Ed. Ra-Ma - 1995
Groenendaal, Kleijnen van - Simulation, a statistical perspective - Ed. Wiley - 1992
RFC 1034 - Domain Names - Implemetation and Specification
RFC 951 - Bootstrap Protocol
RFC 1907 - Management Information Base for version 2 of SNMP
RFC 1442 - Structure of Management Information for version 2 of the Simple Network
Management Protocol (SNMPv2)
RFC 1157 - A Simple Network Management Protocol
Rose, Marshall T. - The Simple Book: An Introduction to Networking Management -
Ed. Prentice-Hall - 1995
Rose, Marshall T. - The internet message: Closing the book with electronic mail.
Siyan, Karanjit S. - Todo Visual J++ - Ed. Inforbook's - 1997
Stallings, William - Data and computer communications - Ed. Prentice-Hall - 1997
Tanenbaum, Andrew S. - Redes de ordenadores - Ed. Prentice-Hall - 1991
Thomas, Patel, Hudson, Ball - Programacin en JAVA para Internet - Ed. Paraninfo - 1997
Tittel, Gaither, Hassinger, Erwin - Fundamentos de programacin con HTML & CGI - Ed. Anaya Multimedia - 1996
Watson, Blackstone - Computer simulation - Ed. Wiley - 1989
Glosario:
MODULE-IDENTITY
OBJECT-TYPE
NOTIFICATION-TYPE
OBJECT IDENTIFIER

Protocolo SNMP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Protocolo SNMP

Uploaded by

Copyright:

Available Formats

1

En una internet se conectan varias redes entre s con el uso de routers y un

La principal tecnologa de interconexin de redes es el conjunto de protocolos de

SNMP se sita en el tope de la capa de transporte de la pila OSI, o por encima de la

1. Necesidad de administrar redes

Los problemas que se presentan en la interconexin de redes son

1. Dispositivos diferentes: La interconexin de redes permite diferentes tipos

2. Administraciones diferentes: Como se permite la interconexin entre redes

.- Evolucin Histrica del Protocolo Simple de Gestin de Red (SNMP)

El protocolo Snmpv1 fue diseado a mediados de los 80 por Case,

En un principio, su principal meta era el lograr una solucin temporal hasta la

El manejo de este protocolo era simple, se basaba en el intercambio de

No obstante este protocolo no era perfecto, adems no estaba pensado para

Introduccin de mecanismos de seguridad, totalmente ausentes en la

Realmente esta versin 2 no supuso mas que un parche, es ms hubo

Aade algunas caractersticas de seguridad como privacidad,

El entorno usado para administracin en los protocolos de Internet se llama

existen dos versiones de este entorno: El entorno original (Internet-standard

Un sistema de administracin de red contiene cinco elementos:

Uno o ms nodos administrables, conteniendo cada uno un agente.

1.1 Nodos Administrables

Un nodo administrable es un dispositivo tal que puede clasificarse un una de

Un Host, como una estacin de trabajo, mainframe, o impresora;

Estas tres categoras coinciden en que clasifican a algn tipo de dispositivo

1.1.1 El Axioma Fundamental

Un buen sistema de administracin de red debe conocer la diversidad

El impacto de aadir una administracin de red a un nodo

El axioma fundamental se debe a las grandes diferencias entre los

1.1.2 Caractersticas de los Nodos Administrables

La interaccin entre estos tres componentes es sencilla: Las instrucciones

1.1.3 Modelo Administrativo

Actualmente los intercambios de informacin son insuficientes para

1.2 Estacin de Administracin de Red

Una estacin de administracin de red es una mquina que ejecuta el

El Axioma Fundamental indica que aadir administracin de red

experiencia muestra que la mayora de las estaciones de trabajo pueden

Hay que tener en cuenta que a medida que hay ms nodos

1.2.1 Entidades de doble funcin

Se ha dicho que las estaciones de administracin slo interactan con

Teniendo esto en cuenta, se pueden construir relaciones jerrquicas

1.3 Protocolo de Administracin de Red

Dependiendo del paradigma que se utilice para la administracin de la

En el entorno de administracin, cada nodo tiene una serie de variables, de

Adems de las operaciones de lectura y escritura, existen otras dos:

Una operacin cruzada, que permite determinar a la estacin de

Veamos un poco ms de ambas operaciones.

1.3.1.1 Operacin de Examen

Como los nodos realizan distintas funciones, tambin contienen diferentes

Un mecanismo para recuperar celdas de una tabla.

1.3.1.2 Operacin de Interrupcin

Desde el comienzo de los sistemas operativos, siempre se ha debatido

Con el mtodo basado en interrupciones, tenemos las siguientes

problema de congestin de la red. Por eso se refina el mtodo de las

En el entorno de administracin se usa el modelo interrupcin-sondeo directo

1.3.2 Forma de transporte

La eleccin de un servicio de transporte por parte del protocolo de

La aplicacin de administracin es la que debe decidir el nivel de fiabilidad

Hay otro motivo para elegir servicios de transporte no orientados a conexin.

en esos casos es cuando realmente la red necesita ser controlada y

1.4 Informacin de Administracin

Finalmente, hemos de explicar la informacin a intercambiar entre la estacin

La caracterstica ms importante de los mtodos usados para describir la

Un efecto lateral de la extensibilidad, es que los vendedores de dispositivos