Compiladores MIB y carga de MIB
Contenido
Introducción
La mayoría de los sistemas de administración de red (NMS) proporcionan un método para que el usuario cargue los MIB. Cargar un MIB es una manera que un NMS aprenda sobre los nuevos objetos MIB, por ejemplo sus nombres, identificadores de objeto (OID) y la clase de tipo de datos (por ejemplo, Contador).
La MIB se podría analizar cuando se carga o podría ocurrir más tarde, por ejemplo, cuando se ejecuta una aplicación NMS. El software que realiza el análisis de datos es un compilador MIB.
Cualquier MIB sintácticamente correcta debe ser analizada con éxito por cualquier compilador MIB del proveedor. Desafortunadamente, diferentes compiladores MIB pueden mostrar diferentes peculiaridades.
Cisco se esfuerza continuamente por garantizar que las MIB publicadas a los clientes sean sintácticamente correctas. Cisco también evita construcciones MIB que han demostrado ser problemáticas en productos NMS populares. A pesar de estos esfuerzos, no es posible satisfacer los rasgos en todos los compiladores MIB en el campo.
Este documento aborda algunos de los problemas comunes y sugiere soluciones alternativas. Si encuentra alguno de estos problemas con el compilador MIB de su proveedor (con la excepción del problema RFC 14xx versus RFC 19xx), se debe a una deficiencia en ese compilador MIB. Es posible que desee instar a su proveedor o proveedores a que corrijan sus compiladores.
Prerequisites
Requirements
Los lectores de este documento deben estar familiarizados con las MIB.
Componentes Utilizados
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Convenciones
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Problemas comunes de carga de MIB
Pedido de carga
El orden de carga es el problema más importante y común al cargar MIB. Muchos MIB utilizan definiciones que se definen en otras MIB. Estas definiciones se detallan en la cláusula IMPORTACIONES en la parte superior del MIB.
Por ejemplo, si el MIB mumble importa una definición del MIB bumble, algunos compiladores de MIB necesitan que cargue el MIB bumble antes de cargar el MIB mumble. Si se produce un error en el orden de carga, el compilador alegará que las MIB importadas no están definidas.
Esta es una lista de MIBs desde las cuales se importan muchas otras MIBs, y el orden en el que se deben cargar. Esto probablemente se ocupa del 95% de los problemas de orden de carga (la mayoría de las otras MIB se pueden cargar en cualquier orden):
-
SNMPv2-SMI.my
-
SNMPv2-TC.my
-
SNMPv2-SMI.my
-
RFC1213-MIB.my
-
IF-MIB.my
-
CISCO-SMI.my
-
CISCO-PRODUCTS-MIB.my
-
CISCO-TC.my
Nota: Si está cargando las versiones v1 de estas MIBs, el nombre de archivo MIB será en realidad similar a IF-MIB-V1SMI.my ("-V1SMI" se agrega al nombre de las MIBs que se han convertido de v2 a v1). La excepción a esto es RFC1213-MIB.my MIB, que sólo existe como versión v1 (es decir, no hay RFC1213-MIB-V1SMI.my).
Si intenta cargar otra MIB, y si el compilador se queja de elementos no definidos, identifique desde qué MIB esta MIB está importando y verifique que primero haya cargado todas las otras MIB.
Nota: Para cada MIB, puede ver la lista exacta de las MIBs que deben cargarse antes—con el orden exacto de compilación—en SNMP Object Navigator > View & Download MIBs; seleccione Ver dependencias MIB y descargar MIB.
Discordancias en las definiciones de tipos de datos
Aunque las definiciones de tipos de datos MIB no serán desiguales, puede ser que ese sea el caso para algunas MIB RFC estándares. Por ejemplo:
-
MIB mumble define: TipoDatos ::= INTEGER(0.100)
-
MIB bumble define: TipoDatos ::= INTEGER(1.50)
A este ejemplo se lo considera como un error trivial y la MIB se carga satisfactoriamente con un mensaje de advertencia.
El siguiente ejemplo se considera un error no trivial (incluso cuando las dos definiciones son esencialmente equivalentes) y el MIB no se analiza exitosamente.
-
MIB mumble define: TipoDeDatos ::= DisplayString
-
MIB bumble define: AlgúnTipo de datos ::= OCTET STRING (SIZE(0.255))
Si su compilador MIB trata estos como errores, o si desea deshacerse de los mensajes de advertencia, edite una de las MIB que definen este mismo tipo de datos para que las definiciones coincidan.
Redefiniciones del identificador de objetos
Puede encontrar redefiniciones de OID si carga estas MIB (aunque puede haber otras instancias donde ocurre este error):
Por ejemplo:
-
OLD-CISCO-CPU-MIB.my define: IDENTIFICADOR DEL OBJETO Lcpu::= { local 1 }
-
OLD-CISCO-ENV-MIB.my define: IDENTIFICADOR DEL OBJETO lenv::= { local 1 }
Cuando carga estas dos MIB, el compilador MIB puede quejarse acerca de que el IDENTIFICADOR DEL OBJETO lcpu se redefine con un nuevo nombre lenv. El OLD-CISCO-MEMORY-MIB.my y el OLD-CISCO-SYSTEM-MIB.my dan nombres nuevos a { local 1 }.
Esto se trata como un error trivial y la MIB se carga satisfactoriamente con un mensaje de advertencia.
Si la MIB no se carga correctamente, o si desea deshacerse del mensaje de advertencia, edite una de las MIB para que todas las MIB utilicen el mismo nombre.
Definiciones de tipos de datos integrados
Muchos compiladores MIB tienen conocimiento integrado de algunos tipos de datos, como DisplayString. Algunos de estos compiladores se quejan si ven una definición para estos tipos de datos en una MIB. Por ejemplo, DisplayString se encuentra definido en SNMPv2-TC.
La solución alternativa es quitar o excluir la definición con problemas del archivo MIB.
Tamaños alternativos
Este es un ejemplo sintácticamente válido, que indica que un valor de tipo MyDattype tendrá 0, 5 o 20 octetos de longitud:
MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
Algunos compiladores MIB no aceptan esta sintaxis. Normalmente, una solución alternativa suficiente es elegir uno de los tamaños y quitar los otros. Debe conservar el tamaño más grande. Por ejemplo, el ejemplo anterior se cambiaría a esto:
MyDatatype ::= OCTET STRING (SIZE(20))
Identificadores de objetos impares
Algunos OID se consideran extraños porque no hacen referencia a un nodo del SMI (como la mayoría de IDENTIFICADORES DE OBJETOS). Sin embargo, son sintácticamente válidos. Un ejemplo común es el identificador de objeto nulo, por ejemplo, { 0 } . Algunos compiladores MIB no se preocupan por los IDENTIFICADORES DE OBJETOS que no corresponden a un nodo del SMI. Estos son ejemplos de sintaxis MIB que podrían causar problemas a estos compiladores:
zeroDotZero OBJECT IDENTIFIER ::= { 0 0 }
myMIBObject OBJECT-TYPE
DEFVAL { {0 0} }
La solución alternativa es quitar o comentar esos tipos de referencias en el archivo MIB.
Definiciones de notificaciones de trampa
En las MIBs SNMPv1, las trampas se definen con la macro TRAP-TYPE. En MIBs SNMPv2, las trampas se definen usando la macro NOTIFICATION-TYPE.
A algunos compiladores MIB no les gustan estas definiciones en los archivos MIB que están analizando (no admiten estas macros).
Si este es el caso, puede quitar las definiciones de trampa o comentar las definiciones (por ejemplo, coloque el delimitador de comentarios MIB — al principio de las líneas).
Compiladores basados en RFC 14xx frente a compiladores basados en RFC 19xx
Los RFC 1442 a 1452 definen el SNMPv2 basado en el partido. Estos RFCs están obsoletos por los nuevos RFCs 1902 a 1908.
Con respecto a la sintaxis MIB, hay muy pocas diferencias entre estas dos versiones de SNMPv2; sin embargo, hay algunos. Las MIB de Cisco se basan actualmente en las reglas RFC 19xx.
Nota: Hace unos años, cuando las MIB de Cisco se basaban en RFC 14xx, algunos compiladores basados en RFC 19xx se quejaban de la línea Unsigned32 ::= TEXTUAL-CONVENTION en CISCO-TC.my y PNNI-MIB.my MIBs. Esto se debe a que Unsigned32 es un tipo de datos predefinido en RFC 19xx. Por esta razón, Cisco solía tener versiones alternativas de estas MIB (CISCO-TC-NO-U32.my y PNNI-MIB-NO-U32.my) sin definición de Unsigned32, para cargar en los compiladores que ya conocen este tipo de datos. Esto ya no es aplicable.
Carga y compilación de MIBS en NMS de terceros
La forma mejor y más eficiente de cargar MIBs, trampas e iconos de Cisco en NMS de terceros es utilizar CiscoWorks Integration Utility (Integration Utility), que está disponible como parte de CiscoWorks Common Services (o independiente desde http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility), con el correspondiente adaptador de Integration Utility desde http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml y el último paquete de datos de Network Management Integration Data Bundle (NMIDB). Consulte la documentación de Integration Utility para obtener más información.
Alternativamente, puede consultar la documentación de NMS de terceros sobre carga y compilación MIB. Este documento incluye instrucciones para HP OpenView e IBM NetView; sin embargo, debe consultar la documentación de HP o IBM, ya que los productos pueden cambiar.
Desde la GUI de HP OpenView o IBM NetView
Siga estos pasos para cargar las MIB de Cisco que desee:
-
Copie los archivos en el directorio /usr/OV/snmp_mibs de la estación de administración de red.
Este es el directorio predeterminado donde HP OpenView e IBM NetView buscan documentos MIB. Si los coloca en cualquier otro lugar, especifique los nombres de trayecto explícitos en la interfaz gráfica loadmib.
-
Establezca los permisos para que tenga acceso de lectura a las MIB.
-
En el menú GUI, elija Options > Load/Unload MIBs.
-
Siga las instrucciones de la documentación de la plataforma para compilar o cargar las MIB de Cisco.
Desde la interfaz de línea de comandos de HP OpenView o IBM NetView
Ejecute el comando /opt/OV/bin/xnmloadmib -load filename para cargar el archivo MIB.
Comentarios