Todos los módulos MIB de SNMP definidos para utilizarse en un dispositivo concreto se componen de la MIB para ese dispositivo. El término MIB a menudo se utiliza para describir una única definición de módulo, pero es técnicamente incorrecto. De hecho, la MIB es la combinación de todos los módulos que se utilizan para gestionar un determinado dispositivo, tanto de hardware como de software. Por tanto, el nombre más preciso para cada módulo definido por un proveedor, o en una RFC, es un módulo MIB de SNMP.
Todos los módulos MIB son al final ampliaciones del módulo raíz. Todos los módulos MIB publicados, de proveedores individuales, provienen del objeto de empresas definido en RFC1155-SMI. Por tanto, todos los agentes SNMP deben dar soporte a RFC1155, y todos los módulos MIB son ampliaciones de RFC1155.
Para hacer extensible la base de información de gestión (MIB) de SNMP, los elementos relacionados se organizan en módulos MIB, que forman una estructura jerárquica. Cada módulo MIB se define dentro de la construcción siguiente:
ModuleName DEFINITIONS ::= BEGIN END
Las etiquetas INICIO Y FIN del módulo permiten definir varios módulos dentro de un único archivo de texto. Los compiladores de MIB deben poder manejar tantos módulos como se definan en un único archivo, pero no debe ser necesario.
Hay convenciones para cada objeto definido en el módulo. Por ejemplo, un nombre de módulo debe empezar por un carácter alfabético en mayúsculas y debe contener sólo letras, números, guiones (-) o guiones bajos (_). Un nombre de objeto debe empezar por un carácter alfabético en minúsculas y debe contener sólo letras, números, guiones (-) o guiones bajos (_). Los comentarios en los módulos MIB se representan mediante dos guiones consecutivos (--) y se puede ignorar cualquier texto que siga al símbolo en cualquier línea.
El diseño modular fácilmente ampliable de las MIB hace que puedan dar soporte a cualquier nueva funcionalidad o dispositivo añadiendo un módulo adicional. Cuando un módulo se escribe como ampliación de otro módulo, incluye la sección IMPORTS, que se encuentra debajo de la línea DEFINITIONS. La sección IMPORTS define los objetos requeridos por módulos superiores de la jerarquía MIB y los módulos en los que están definidos por turnos.
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress,
IpAddress, TimeTicks FROM RFC1155-SMI;A menudo se cometen errores tipográficos al especificar nombres de MIB importados. Por ejemplo, RFC1212 puede ser referenciado como módulo MIB en vez del nombre correcto, RFC-1212. Si MIB Manager resalta errores de análisis, debe verificar la sección IMPORTS para confirmar que los nombres de los módulos MIB son correctos. Algunos módulos MIB también contienen la sección EXPORTS (que también termina en un punto y coma). Esta sección informa al lector de que el autor de MIB prevé que otros módulos MIB utilicen los mismos objetos especificados. Para nuestros fines, esta sección es irrelevante y se puede ignorar.
Los módulos MIB de SNMP se definen en un formato denominado ASN.13 (Notación Sintáctica Abstracta 1.) SNMP, sin embargo, sólo utiliza una parte de ASN.14. ASN.1 está definida en ITU-T X.208 y en ISO 8824. Las partes de ASN.1 concernientes a SNMP están definidas en RFC1155. RFC1155 define los siguientes tipos de datos de SNMP válidos:
Un tipo definido es el mecanismo utilizado para especificar un determinado formato para un tipo primitivo o constructor. Es posible que los autores de MIB definan tipos definidos utilizando la construcción TEXTUAL-CONVENTION.
DisplayString ::= OCTET STRING (0..255)DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Representa información textual
tomada del juego de caracteres NVT ASCII, como se define en las páginas 4, 10-11 de RFC 854. Para resumir RFC 854, el repertorio NVT ASCII
especifica: - uso de código de caracteres 0-127 (decimal) -los caracteres gráficos
(32-126) se interpretan como US ASCII - NUL, LF, CR, BEL, BS, HT, VT y FF tienen los
significados especiales especificados en RFC 854 - los otros 25 códigos no tienen una interpretación estándar
- la secuencia 'CR LF' significa una nueva línea - la secuencia 'CR NUL' significa
retorno de carro - un 'LF' no precedido de un 'CR' significa moverse a la misma columna en
la siguiente línea. - la secuencia "CR x" para cualquier x distinta de LF o NUL es ilegal. (Tenga en cuenta que esto también significa que una serie puede acabar con 'CR LF' o 'CR NUL',
pero no con CR.) Los objetos definidos con esta sintaxis no pueden exceder de 255 caracteres de longitud." SYNTAX OCTET STRING (SIZE (0..255))Otro error común que se comete al escribir módulos MIB es crear un nombre de objeto que no es exclusivo. Se dice que la sentencia RFC1155 significa que sólo deben ser exclusivos los objetos dentro de un único módulo MIB. Como se ha mencionado antes, la MIB es el conjunto completo de módulos que, combinados, se utilizan para gestionar un determinado dispositivo. Por tanto, todos los objetos definidos en un módulo MIB deben ser exclusivos, no sólo en su propio módulo, sino también en los otros nombres de objeto en los módulos importados, y los módulos que esos módulos puedan importar. Un mecanismo habitual para garantizar que los nombres de objeto sean exclusivos es prefijar a todos los nombres de módulo el símbolo ticker de la empresa o el nombre de la empresa abreviado.
Cuando se definen objetos se correlacionan en una jerarquía numérica que se parece a un árbol de expansión. Cada vez que se define un objeto, se define como hoja de un objeto padre. Los siguientes tres objetos raíz se definen en el árbol MIB de SNMP:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(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 }Estas definiciones indican el nombre de objeto, los tipos de objeto asociados, el nombre del padre de cada objeto (o lista ordenada de padres) y el número de hoja de este hijo al padre (o padres). Gráficamente, estos elementos adoptan una forma jerárquica.
Puede desplazarse por la vista Árbol MIB expandiendo y contrayendo los nodos del árbol MIB. Las ramificaciones del nivel superior del árbol MIB contienen los nombres de los módulos MIB, y dentro de cada ramificación de módulo MIB se encuentran los otros elementos que componen la MIB. A medida que se añaden módulos adicionales a la MIB, se añaden objetos adicionales al árbol MIB. Se puede aludir a cada objeto por su nombre de objeto o por su identificador de objeto (OID). El método más preciso es hacer referencia a su OID. Su OID se define como su número, y cada uno de los números de su ancestro hasta el nodo raíz están concatenados con un punto (.) que los separa. El OID para el objeto de las empresas (nodo u hoja) es 1.3.6.1.4.1.
Muchos proveedores no se aseguran de que sus nombres de objeto sean exclusivos universalmente y, por tanto, es posible que dos proveedores tengan un objeto con el mismo nombre. Esto hace que la utilización del nombre de objeto para identificar un objeto sea un poco ambiguo.