IBM Tivoli Netcool/OMNIbus Versão 8.1

Design de conceito MIB

Todos os módulos MIB SNMP que são definidos para uso por um determinado dispositivo incluem a MIB para esse dispositivo. O termo MIB é frequentemente usado para descrever uma única definição de módulo, mas isto é tecnicamente incorreto. De fato, a MIB é a combinação de todos os módulos usados para gerenciar um dispositivo específico, quer o dispositivo se relacione com hardware ou software. Por esta razão, o nome mais preciso para cada módulo definido por um fornecedor ou em um RFC, é módulo MIB SNMP.

Todos os módulos MIB são no final extensões do módulo raiz. Todos os módulos MIB liberados, de fornecedores individuais, estendidos de objetos de empresas definidos no RFC1155-SMI. Por esta razão, todos os agentes SNMP devem suportar o RFC1155 e todos os módulos MIB são extensões do RFC1155.

Structure of Management Information (SMI)

Para tornar a base de informações de gerenciamento (MIB) SNMP extensível, os itens relacionados são organizados nos módulos MIB que formam uma hierarquia estruturada. Cada módulo MIB é definido dentro da construção a seguir:

ModuleName DEFINITIONS ::= BEGIN END

As tags BEGIN e END no módulo permitem que diversos módulos sejam definidos dentro de um arquivo de texto único. Os compiladores MIB deverão estar aptos a manipular qualquer número de módulos definidos em um único arquivo, mas não deverão requerê-lo.

Há convenções para cada objeto definido no módulo. Por exemplo, um nome de módulo deve iniciar com um caractere alfabético maiúsculo e conter apenas letras, números, hifens (-) ou sublinhados (_). Um nome do objeto deve iniciar com um caractere alfabético minúsculo e deve conter apenas letras, números, hifens ou sublinhados. Comentários nos módulos MIB são representados por dois hifens consecutivos (--) e qualquer texto após este símbolo, em qualquer linha, pode ser ignorado.

O design modular e facilmente extensível das MIBs as tornam aptas a suportar qualquer nova funcionalidade ou dispositivo ao incluir um módulo adicional. Quando um módulo é gravado como uma extensão de outro módulo, ele incluirá uma seção IMPORTS, localizada abaixo da linha DEFINITIONS. A seção IMPORTS define os objetos requeridos por módulos superiores na hierarquia da MIB e os módulos nos quais eles são definidos.

A definição a seguir é do RFC1157 e indica vários objetos importados do RFC1155. Esta seção pode ser visualizada como análoga à instrução include em uma linguagem de programação como C ou Perl ou em um arquivo de regras Netcool. Além disso, para entender os objetos no módulo MIB atual (RFC1157-SNMP) é necessário também conhecer os objetos no módulo MIB anterior (RFC1155-SMI).
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI;

Erros tipográficos são feitos facilmente ao especificar nomes de MIB importados. Por exemplo, RFC1212 pode ser referenciado como um módulo MIB ao invés do nome correto, RFC-1212. Se erros na análise forem destacados pelo MIB Manager, deve-se verificar a seção IMPORTS para confirmar se os módulos MIB estão corretamente nomeados. Alguns módulos MIB também contêm uma seção EXPORTS (que também termina com um ponto e vírgula). A seção informa o leitor que o autor do MIB espera que outros módulos MIB usem os mesmos objetos especificados. Para nossos propósitos, esta seção é irrelevante e pode ser ignorada.

Tipos de Dados Definidos

Os módulos MIB SNMP são definidos em um formato conhecido como ASN.13 (Abstract Syntax Notation 1). O SNMP, entretanto, usa apenas uma porção do ASN.14. O ASN.1 é definido no ITU-T X.208 e no ISO 8824. As porções do ASN.1 que se aplicam ao SNMP são definidas no RFC1155. O RFC1155 define os tipos de dados SNMP válidos a seguir:

Um tipo definido é um mecanismo usado para simplificar um formato em especial para tipos primitivos ou de construtor. Autores de MIB podem definir tipos adicionais usando a construção CONVENÇÃO TEXTUAL.

DisplayString é um bom exemplo de um tipo definido. No módulo SNMPv2-SMI-v1 MIB, a versão v1 do DisplayString tem a definição a seguir:
DisplayString ::= OCTET STRING (0..255)
No módulo SNMPv2-TC MIB, a versão v2 do DisplayString tem a definição a seguir:
DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS DESCRIÇÃO atual "Representa informações textuais tomadas do conjunto de caracteres NVT ASCII, conforme definido nas páginas 4, 10-11 do RFC 854. Para resumir
o RFC 854, o repertório NVT ASCII 
especifica: - o uso dos códigos de caracteres 0-127 (decimal) - os caracteres gráficos 
(32-126) são interpretados como US ASCII - NUL, LF, CR, BEL, BS, HT, VT e FF possuem os 
significados especiais especificados no RFC 854 - os outros 25 códigos não possuem 
interpretação padrão - a sequência 'CR LF' significa nova linha - a sequência 'CR NUL' significa 
retorno de linha - um 'LF' não precedido por um 'CR' significa mover para a mesma coluna na 
próxima linha. - a sequência 'CR x' para qualquer x diferente de LF ou NUL é ilegal. 
(Note que isto também significa que uma sequência pode terminar com 'CR LF' ou 'CR NUL', mas não com CR.) Qualquer objeto definido usando esta sintaxe não poderá exceder 255 caracteres de comprimento". SYNTAX OCTET STRING (SIZE (0..255))
O exemplo acima mostra que um DisplayString é uma SEQUÊNCIA DE OCTETOS de 0 a 255 caracteres de comprimento. Note que cada DESCRITOR DE OBJETO que corresponda a um tipo de objeto em um MIB padrão internet, deve ser uma sequência exclusiva, mnemônica e para impressão.

Definindo Objetos

Um erro comum cometido ao compor módulos MIB é criar um nome de objeto que não é exclusivo. Alega-se que a instrução RFC1155 significa que somente objetos em um módulo MIB único devem ser exclusivos. Conforme discutido anteriormente, o MIB é o conjunto completo de módulos que, quando combinados, são usados para gerenciar um dispositivo em especial. Por esta razão, todos os objetos definidos em qualquer módulo MIB deverão ser exclusivos, não apenas em seu próprio módulo, mas também em qualquer outro nome do objeto em quaisquer módulos importados e em quaisquer módulos que estes possam importar. Um mecanismo comum para assegurar que nomes de objetos sejam exclusivos é pré-anexar todos os nomes de módulos com o símbolo ticker da empresa ou nome da empresa abreviado.

Quando objetos são definidos, eles são mapeados em uma hierarquia que se assemelha a uma árvore de amplitude. A cada vez que um objeto é definido, ele é definido como uma folha de um objeto-pai. Os três objetos raiz a seguir são definidos na árvore MIB SNMP:

Todos os outros nós na árvore MIB são filhos desses três nós raiz. Por exemplo, RFC1155-SMI define os objetos a seguir:
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 definições indicam o nome do objeto, os tipos de objetos associados, o nome do pai de cada objeto (ou a lista ordenada dos pais) e o número da folha do filho daquele pai (ou pais). Graficamente, esses itens assumem uma forma hierárquica.

É possível transitar pela visualização da árvore MIB expandindo e reduzindo nós na árvore MIB. As ramificações de nível superior da árvore MIB contém os nomes dos módulos MIB e, contidos estão em cada ramificação do módulo MIB os outros elementos que englobam o MIB. À medida que os módulos são incluídos no MIB, objetos adicionais são incluídos à árvore MIB. Cada objeto pode ser referido por seu nome do objeto ou por seu identificador de objeto (OID). O método mais preciso é referenciar pelo seu OID. Seu OID é definido como seu número e cada um de seus números de ancestral continuando até o nó raiz, concatenado junto com um ponto final (.) separando cada um deles. O OID para objetos corporativos (nó ou folha) é 1.3.6.1.4.1.

Muitos fornecedores não asseguraram que seus nomes de objetos sejam universalmente exclusivos, portanto, é possível que dois fornecedores tenham um objeto compartilhando o mesmo nome. O que torna o uso do nome do objeto para identificar o objeto um tanto ambíguo.


Biblioteca | Suporte |