MIB Compilers and Loading MIBs
Contents
Introduction
A maioria dos sistemas de gerenciamento de rede (NMS) fornecem uma maneira do usuário carregar MIBs. Carregar um MIB é uma maneira de um NMS aprender sobre novos objetos MIB, como seus nomes, identificadores de objeto (OID) e qual tipo de dados (por exemplo: Contador).
A MIB pode ser analisada quando é carregada ou pode ocorrer mais tarde, por exemplo, quando um aplicativo NMS é executado. O software que executa a análise é um compilador MIB.
Qualquer MIB sintaticamente correta deve ser analisada com êxito por qualquer compilador MIB do fornecedor. Infelizmente, diferentes compiladores MIB podem exibir diferentes caprichos.
A Cisco faz esforços contínuos para garantir que as MIBs publicadas para os clientes sejam sintacticamente corretas. A Cisco também evita construções de MIB que provaram ser problemáticas em produtos populares de NMS. Apesar desses esforços, não é possível satisfazer as peculiaridades de todos os compiladores MIB no campo.
Este documento aborda alguns dos problemas comuns e sugere soluções alternativas. Se você encontrar algum desses problemas com o compilador MIB do seu fornecedor (com exceção do problema RFC 14xx versus RFC 19xx), isso é devido a uma deficiência nesse compilador MIB. Você pode pedir que o fornecedor ou fornecedores corrijam seus compiladores.
Prerequisites
Requirements
Os leitores deste documento devem estar familiarizados com MIBs.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
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.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Problemas comuns de carregamento de MIB
Ordem de carga
A ordem de carregamento é o problema mais importante e comum quando você está carregando MIBs. Muitas MIBs usam definições que são definidas em outras MIBs. Essas definições estão listadas na cláusula IMPORTS próxima à parte superior do MIB.
Por exemplo, se o MIB mumble importar uma definição do MIB bumble, alguns compiladores MIB requerem que o MIB bumble seja carregado antes de carregar o MIB mumble. Se você obtiver a ordem de carga errada, o compilador reivindicará que os MIBs importados não estão definidos.
Esta é uma lista de MIBs das quais muitos outros MIBs importam e a ordem na qual você deve carregá-los. Isso provavelmente resolve 95% dos problemas de ordem de carga (a maioria das outras MIBs pode ser carregada em qualquer ordem):
-
SNMPv2-SMI.my
-
SNMPv2-TC.my
-
SNMPv2-MIB.my
-
RFC1213-MIB.my
-
IF-MIB.my
-
CISCO-SMI.my
-
PRODUTOS CISCO-MIB.my
-
CISCO-TC.my
Observação: se você estiver carregando as versões v1 desses MIBs, o nome do arquivo MIB realmente parecerá com IF-MIB-V1SMI.my ("-V1SMI" é adicionado ao nome dos MIBs que foram convertidos de v2 para v1). A exceção a isso é o RFC1213-MIB.my MIB, que existe apenas como uma versão v1 (ou seja, não há RFC1213-MIB-V1SMI.my).
Se você tentar carregar outra MIB, e se o compilador reclamar sobre itens indefinidos, identifique de quais MIBs esta MIB está importando e verifique se você carregou todos os outros MIBs primeiro.
Observação: para cada MIB, você pode ver a lista exata dos MIBs que precisam ser carregados antes dele—com a ordem exata de compilação—no SNMP Object Navigator > Exibir e baixar MIBs; selecione Exibir dependências MIB e baixe MIB.
Incompatibilidades em definições de tipos de dados
Embora as definições de tipo de dado do Cisco MIB não sejam incompatíveis, pode ser que você entenda dessa forma no caso de alguns MIBs de RFC padrão. Por exemplo:
-
O MIB mumble define: Algum tipo de dados ::= INTEGER(0.100)
-
O conjunto MIB define: Algum tipo de dados ::= INTEGER(1.50)
Este exemplo é considerado um erro trivial e o MIB é carregado com êxito com uma mensagem de advertência.
O exemplo a seguir é considerado como sendo um erro não-trivial (mesmo se as duas definições forem equivalentes), e a MIB não é analisada com êxito.
-
O MIB mumble define: Algum tipo de dados::= DisplayString
-
O conjunto MIB define: Algum tipo de dados ::= STRING DE OCTETO (TAMANHO(0.255))
Se o compilador MIB tratar esses erros como erros ou se você quiser se livrar das mensagens de aviso, edite um dos MIBs que definem esse mesmo tipo de dados para que as definições correspondam.
Redefinições de Identificador de Objeto
Você pode encontrar redefinições de OID se carregar essas MIBs (embora possa haver outras instâncias onde esse erro ocorre):
Por exemplo:
-
OLD-CISCO-CPU-MIB.my define: lcpu OBJECT IDENTIFIER ::= { local 1 }
-
OLD-CISCO-ENV-MIB.my define: lenv OBJECT IDENTIFIER ::= { local 1 }
Quando você carrega esses dois MIBs, o compilador MIB pode reclamar sobre o lcpu OBJECT IDENTIFIER sendo redefinido com um novo nome lenv. O OLD-CISCO-MEMORY-MIB.my e o OLD-CISCO-SYSTEM-MIB.my também dão novos nomes para { local 1 }.
Isso é tratado como um erro trivial e o MIB é carregado com êxito com uma mensagem de erro.
Se o MIB não for carregado com êxito ou se você quiser se livrar da mensagem de aviso, edite um dos MIBs para que todos os MIBs usem o mesmo nome.
Definições dos tipos de dados embutidos
Muitos compiladores MIB têm conhecimento interno de alguns tipos de dados, como DisplayString. Alguns desses compiladores reclamam se veem uma definição para esses tipos de dados em uma MIB. Por exemplo, DisplayString é definido em SNMPv2-TC.
A solução é remover ou assinalar como comentário a definição ofensiva no arquivo MIB.
Tamanhos alternativos
Este é um exemplo sintaticamente válido, que indica que um valor do tipo MyDatatype terá 0, 5 ou 20 octetos de comprimento:
MyDatatype ::= OCTET STRING (SIZE(0 | 5 | 20))
Alguns compiladores MIB não aceitam esta sintaxe. Geralmente, uma solução alternativa suficiente é escolher um dos tamanhos e remover os outros. Você deveria manter o maior tamanho. Por exemplo, o exemplo anterior seria alterado para este:
MyDatatype ::= OCTET STRING (SIZE(20))
Identificadores de objeto ímpar
Alguns OIDs são considerados estranhos porque não se referem a um nó no SMI (como a maioria dos OBJECT IDENTIFIERs). No entanto, elas são sintacticamente válidas. Um exemplo comum é o identificador de objeto nulo, por exemplo, { 0 0 }. Alguns compiladores MIB não se preocupam com IDENTIFICADORES OBJECT que não correspondem a um nó no SMI. Estes são exemplos de sintaxe MIB que podem causar problemas para estes compiladores:
zeroDotZero OBJECT IDENTIFIER ::= { 0 0 }
myMIBObject OBJECT-TYPE
DEFVAL { {0 0} }
A solução é remover ou comentar esses tipos de referências no arquivo MIB.
Definições de armadilhas
Em MIBs SNMPv1, as interceptações são definidas com a macro TRAP-TYPE. Em MIBs SNMPv2, as armadilhas são definidas usando a macro NOTIFICATION-TYPE.
Alguns compiladores MIB não gostam dessas definições nos arquivos MIB que estão analisando (eles não suportam essas macros).
Se for esse o caso, você pode remover as definições de interceptação (trap) ou comentar as definições (por exemplo, colocar o delimitador de comentário MIB — no início das linhas).
Compiladores baseados em RFC 14xx versus Compiladores baseados em RFC 19xx
Os RFCs 1442 a 1452 definem o SNMPv2 baseado em partes. Esses RFCs são obsoletos pelos RFCs de Rascunho mais recentes de 1902 a 1908.
No que diz respeito à sintaxe MIB, há muito poucas diferenças entre essas duas versões de SNMPv2; há algumas, no entanto. As MIBs da Cisco são baseadas atualmente nas regras RFC 19xx.
Observação: há alguns anos, quando os MIBs da Cisco eram baseados em RFC 14xx, alguns compiladores baseados em RFC 19xx reclamavam da linha Unsigned32 ::= TEXTUAL-CONVENTION em MIBs CISCO-TC.my e PNNI-MIB.my. Isso porque Unsigned32 é um tipo de dados predefinido no RFC 19xx. Por esse motivo, a Cisco costumava ter versões alternativas desses MIBs (CISCO-TC-NO-U32.my e PNNI-MIB-NO-U32.my) sem definição para Unsigned32, para carregar os compiladores que já sabem sobre esse tipo de dados. Isso não é mais aplicável.
Carregando e compilando MIBS em NMS de terceiros
A melhor e mais eficiente maneira de carregar MIBs, armadilhas e ícones da Cisco em NMS de terceiros é usar o CiscoWorks Integration Utility (Integration Utility), que está disponível como parte do CiscoWorks Common Services (ou independente de http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility), com o correspondente Integration Utility Adapter de http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml e o mais recente Network Management Integration Data Bundle (NMIDB). Consulte a documentação do Integration Utility para obter mais detalhes.
Como alternativa, você pode consultar a documentação do NMS de terceiros sobre carregamento e compilação de MIB. Este documento inclui instruções para o HP OpenView e o IBM NetView; mas você ainda deve consultar a documentação da HP ou da IBM, pois os produtos podem mudar.
Na GUI do HP OpenView ou IBM NetView
Siga estas etapas para carregar os MIBs da Cisco desejados:
-
Copie os arquivos no diretório /usr/OV/snmp_mibs da estação de gerenciamento de rede.
Este é o diretório padrão onde o HP OpenView e o IBM NetView procuram documentos MIB. Se você colocá-los em outro lugar, especifique os nomes explícitos do caminho na interface gráfica loadmib.
-
Defina as permissões para que você tenha acesso de leitura aos MIBs.
-
No menu da GUI, escolha Options > Load/Unload MIBs.
-
Siga as instruções na documentação da plataforma para compilar ou carregar os MIBs da Cisco.
Da interface de linha de comando do HP OpenView ou IBM NetView
Emita o comando /opt/OV/bin/xnmloadmib -load filename para carregar o arquivo MIB.
Feedback