Este tópico descreve os tipos de objetos definidos no SNMP v1 e v2.
É possível localizar as informações do objeto descritas nas seções a seguir ao selecionar um módulo na visualização Módulos MIB e, então, procurar por ifIndex no campo Procura da visualização Árvore OID. Clique no objeto ifIndex na hierarquia Árvore OID para visualizar informações sobre o objeto e informações sobre convenção textual na visualização Detalhes.
O OBJECT IDENTIFIER é definido pelo SNMP v1 e é o bloco de construção principal da árvore MIB. Identificadores de objeto são análogos a um título de capítulo em um livro - eles não contêm dados reais, mas fornece uma ideia de qual tipo de conteúdo é retransmitido por seus descendentes.
O OBJECT TYPE é definido pelo SNMP v1 e é usado como um contêiner para armazenar informações sobre o dispositivo gerenciado ou algum valor medido no dispositivo.
A TEXTUAL CONVENTION (TC) é uma definição de um tipo de objeto, mas não é um objeto real. Na visualização Módulos MIB, é possível selecionar Convenções Textuais a partir da lista Visualizar para visualizar as convenções textuais analisadas exibidas na árvore MIB. Selecione um nome de TC na árvore MIB para exibir suas definições na visualização Detalhes.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 A seção ENTERPRISE define qual objeto é o pai do trap. Entretanto, é possível que um objeto da árvore MIB seja definido com bgp como o pai e é definido como filho número 1. De fato, bgpVersion é definido como { bgp 1} no módulo RFC1269-MIB. Por esta razão, é impossível incluir um trap v1 à árvore MIB como uma folha usando o ENTERPRISE como pai.
O SNMP v2 altera a definição do TRAP-TYPE para NOTIFICATION-TYPE e especifica que este novo trap v2 seja definido como outros objetos MIB, com um número para o pai e outro para o filho tornando isso um problema para os traps v1 . RFC1155 Section 4.1 define que o uso de zero (0) como um número de filho é inválido e reservado para uso futuro. O SNMP v2 faz uso daquele zero para permitir que os fornecedores incluam seus traps v1 para um MIB v2, incluindo um zero ao nome da empresa e em seguida incluindo o número do trap depois do zero. Portanto, na v2 é apropriado definir um identificador de objeto com um zero como um filho da empresa e, então, incluir os traps v1 como filhos de tal zero.
Esta convenção causou outro erro comum feito pelos autores do MIB. A Seção 4 do RFC1155 determina o seguinte:
"Uma definição de tipo de objeto consiste em cinco campos: OBJETO: ------- Um nome textual, expresso como DESCRITOR DO OBJETO, para o tipo de objeto, junto com seu IDENTIFICADOR DE OBJETO correspondente. Sintaxe: A sintaxe abstrata para o tipo de objeto. Isto deverá resolver para uma instância do ASN.1 tipo ObjectSyntax (definida abaixo). Definição: uma descrição textual da semântica do tipo de objeto. As implementações deverão assegurar que suas instâncias do objeto cumprem esta definição já que o propósito do MIB é o de ser usado em ambientes de diversos fornecedores. Como tal é vital que os objetos tenham significado consistente em todas as máquinas. Acesso: Um dos seguintes, somente leitura, leitura/gravação, somente gravação ou não acessível. Status: Um dos seguintes, obrigatório, opcional ou obsoleto. Memorandos futuros também podem especificar outros campos para os objetos que eles definem."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } Objetos que são transmitidos com o trap v1 ou a notificação v2 são conhecidos como varbinds. Varbinds contêm informações adicionais sobre o evento relatado. Em um trap v1, os varbinds são detalhados em itens na seção VARIABLES e em uma notificação v2, os varbinds são listados na seção OBJETOS. Eles têm o mesmo uso em todas as versões do SNMP. A ordem na qual os varbinds aparecem na lista é importante porque o PDU (Pacote SNMP) codifica os valores associados na mesma ordem na qual eles são listados na MIB.
Por exemplo, na seção OBJECTS, os três varbinds a seguir foram especificados: ifIndex, ifAdminStatus e ifOperStatus. Portanto, ifIndex é o primeiro varbind a ser codificado, ifAdminStatus é o segundo e ifOperStatus é o terceiro a ser codificado. Verificando o IF-MIB descobrimos que o tipo de objeto ifIndex é definido como InterfaceIndex. Como este não é um tipo ASN.1 primitivo válido para SNMP, ele deve ser uma convenção textual. Procurando em convenções textuais, descobrimos que InterfaceIndex realmente resolve para um Integer32 (número inteiro de 32 bits). Portanto, quando o PDU chegar ao MIB Manager, o primeiro varbind será um número inteiro. Para determinar o que esse número inteiro significa, o MIB Manager deve referenciar o módulo IF-MIB, consultar ifIndex e ler as informações do objeto associado. Verificando o segundo varbind, descobrimos um tipo de número inteiro enumerado:
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }Quando o varbind é decodificado a partir do pacote SNMP, seu valor será um número inteiro, o valor do qual deve ser interpretado com base nos itens nesta lista enumerada. Quando o MIB Manager for usado para criar um arquivo de regras, ele criará uma tabela de consulta para vincular automaticamente o número inteiro enumerado com sua representação textual. O terceiro varbind também é um tipo enumerado com os mesmos valores. Portanto, se o ifAdminStatus for 1 (para cima) e o ifOperStatus for 2 (para baixo), sabemos porque o evento foi gerado e pode continuar a tentar determinar a causa desta indisponibilidade.
Varbinds são apresentados para o usuário em um arquivo de regras como $1, $2, $3e assim por diante, com cada número representando um número de varbind. O MIB Manager cria elementos com base nos elementos varbind e os usa para configurar variáveis na tabela de detalhes. Por exemplo, os elementos usados nos detalhes da tabela podem ser $ifIndex = $1, que será um número inteiro, $ifAdminStatus = $2, que será alguma coisa como (1), e $ifOperStatus = $3, o que será algo como (3). Quaisquer mudanças feitas nas configurações de objeto são automaticamente configuradas no arquivo de regras, usando as convenções configuradas pela Netcool Knowledge Library (NCKL).
Tabelas representam o equivalente a uma matriz multidimensional com linhas e colunas de dados. O objeto da tabela é definido como uma SEQUENCE OF de um objeto de Entrada. O objeto de Entrada é em seguida definido como objeto SEQUENCE of OBJECT-TYPE. Ocasionalmente, um fornecedor projeta um sistema não usual, por exemplo, o roteador Cisco 10k. Este dispositivo mantém uma tabela interna de condições de alarme e gera um trap ou notificação quando a tabela muda. Em seguida é necessário emitir uma solicitação SNMP GET sobre o conteúdo da tabela para determinar o status atual dos alarmes ativos no dispositivo. Isto torna a obtenção de alarmes pelo gerenciador de SNMP um pouco mais difícil, mas não impossível se o administrador tiver as ferramentas adequadas.
Um octeto é uma construção de dados que consiste em oito bits (comumente conhecida como um byte). Portanto uma SEQUÊNCIA DE OCTETOS, é uma matriz de bytes (ou uma sequência de bytes). O termo SEQUÊNCIA DE OCTETOS não significa que todos os bytes na sequência são alfanuméricos. Também podem ser caracteres binários e serem usados como máscara de bits.