Comunidades e Nome de Comunidade
O gerenciamento de redes pode ser visto como uma aplicação distribuída. Como qualquer outra aplicação distribuída, o gerenciamento da rede envolve um número da entidade de aplicação, suportada por um protocolo de aplicação. No caso do gerenciamento de rede SNMP, as entidades de aplicação são as aplicações da estação de gerenciamento e a aplicação da estação administrada(agente) que usam SNMP, que é o protocolo suportado.
Cada controle do agente está em local próprio na MIB e deve ser capaz de controlar o uso desta MIB por estações de gerenciamento. Esses controles tem três aspectos:
Serviço de Autenticação
Um serviço de autenticação está interessado em garantir que uma comunidade seja autêntica. No caso de uma mensagem SNMP, a função de um serviço de autenticação deveria ser garantir ao recipiente que a mensagem é da origem que ele afirma ser. O procedimento de autenticação deveria envolver o uso de criptografia/descriptografia para maior segurança nas funções de autenticação.
Plano de Acesso
Definindo uma comunidade, um agente limita acesso para a MIB para selecionar conjuntos de estações de gerenciamento. Usando mais que uma comunidade, o agente pode prover diferentes categorias de acesso MIB para diferentes estações de gerenciamento. Esse controle de acesso tem dois aspectos:
1 - SNMP MIB: um subconjunto de objetos dentro de uma MIB. Diferentes MIBs podem ser definidos para cada comunidade. O conjunto de objetos em um aspecto não necessita ter seu lugar próprio em uma simples sub-árvore da MIB.
2 - Modo de Acesso SNMP: um elemento do conjunto {Read-Only, Read-write}. Cada comunidade tem seu modo de acesso.
Um profile da comunidade é associada com cada comunidade definida por um agente; a combinação de uma comunidade SNMP e um PROFILE da comunidade SNMP é referido como por exemplo, um Plano de Acesso SNMP.
Serviço de Proxy
O conceito de comunidade é também proveitoso em suporte ao Serviço de Proxy. Tipicamente, os outros dispositivos são externos, no sentido que eles não suportam TCP/IP e SNMP, mas a proxy é usada para minimizar a interação entre o dispositivo procurado e o sistema de gerenciamento da rede.
Para cada dispositivo que o sistema procuração representa, ele mantém um sistema de plano de acesso SNMP. Deste modo a informação proxy que objetos MIB podem ser usados para administrar os sistema proxied e seus modos de acesso.
Identificação de Instância:
Cada objeto em uma MIB tem um único objeto identificado que é definido pela posição do objeto na árvore estruturada MIB. Quando um acesso é feito por uma MIB, via SNMP ou algum outro modo, é uma instância específica de um objeto que é necessitado, não um tipo de objeto.
Objetos Colunares
Para objetos que aparecem em tabelas, que são referidos à objetos colunares, o identificador do objeto, não é suficiente para identificar a instância: então é uma instância de objeto para toda ROW na tabela. Portanto, alguma convenção é necessária para que uma instância específica de um objeto dentro da tabela possa ser identificada. A SMI especifica que: os meios pelos quais instâncias de objetos são referenciados não está na MIB. Referências à instâncias de objetos são realizadas por um mecanismo específico do protocolo. É responsável por cada protocolo de gerência adicionadas ao SMI para definir este mecanismo.
SNMP atualmente define duas técnicas para identificar uma instância específica do objeto: uma técnica de acesso serial e uma técnica de acesso randômico.
É relativamente fácil deduzir o tipo de convenção de referenciamento que deve ser usado. Uma tabela consiste em um conjunto de zero ou mais linhas. Cada linha contém o mesmo conjunto de tipos de objetos escalares ou objetos colunares.
Grupo Tabela Identificadores de LINHA Identificadores de ObjetoInterfaces ifTable 1.3.6.1.2.1.2.2.1 x.i.(ifIndex)
Addres trans- atTable 1.3.5.1.2.1.3.1.1 x.i.(atIfIndex).(atNetAddres)
lation
IP ipAddrTable 1.3.6.1.2.1.4.20.1 x.i.(ipAdEntAddr)
IP ipRouteTable 1.3.6.1.2.1.4.21.1 x.i.(ipRouteDest)
IP ipNetToMediaTable 1.3.6.1.2.1.4.22.1 x.i.(ipNetToMediaIfIndex.)
(ipNetToMediaType)
TCP tcpConnTable 1.3.6.1.2.1.6.13.1 x.i(tcpConnLocalAddress).
(tcpConnLocalPort).
(tcpConnRemAddress).
(tcpConnRemPort)
UDP udpTable 1.3.6.1.2.1.7.5.1 x.i(udpLocalAddress).
(udpLocalPort)
EGP egpNeighTable 1.3.6.1.2.1.8.5.1 x.i(egpNeighAddr)
A tabela mostra a forma do identificador de instância para todas as tabelas na MIBII.
Um detalhe que deve ser trabalhado na saída é como o valor de uma instância do objeto é convertido em um ou mais subidentificadores. A emissão não é especificamente endereçada no documento SNMP(RFC 1157). O RFC 1212, que define a macro OBJECT-TYPE usada pela MIBII, inclui as seguintes regras para cada índice da instância do objeto.
Valor Inteiro: um subidentificador pega o valor inteiro(válido somente para inteiros positivos).
Valor String, Tamanho Fixo: cada octeto da string é representado como um subidentificador separado, para um total de n subidentificadores para uma string de n octetos.
Valor String, Tamanho Variável: para um string de n octetos, o primeiro subidentificar n; seguido por cada octeto da string representado como um subidentificador separado, para total de n+1 subidentificadores.
Valor Identificador do Objeto: para um identificador do objeto com n subidentificadores, o primeiro subidentificador é n; seguido pelo valor de cada subidentificador em ordem, para um total de n+1 subidentificadores.
Valor Endereço IP: Quatro subidentificadores, na notação a.b.c.d.
O Problema de Referência Ambígua à Tabela
No RFC 1212, a cláusula INDEX para a macro OBJECT-TYPE está definida na classe que é proposta para listar o objeto ou objetos cujo valor do objeto distinguirá uma linha conceitual.
Por exemplo, o objeto INDEX da ipRouteTable, no grupo IP, é ipRouteDest. Entretanto, não é sempre o caso de que somente um roteamento simples será armazenado para um dado destino. Neste caso, duas linhas terão o mesmo valor para ipRouteDest, e o esquema da identificação da instância apenas descreverá os resultados nas duas ou mais instâncias de objetos com o mesmo identificador da instância.
Uma forma sobre o problema proposto é adicionar outro subidentificador de instância, sob controle do agente. Quando duas ou mais colunas tem o mesmo valor do objeto INDEX, o agente designa tal tabela como secundária e inclui o subidentificador 2 e assim em diante.
Tabela Conceitual e Linhas de Objetos
Para tabela e coluna de objetos, não está definido um identificador de instâncias. Isto é porque estes objetos não são acessíveis por SNMP. Na definição da MIB destes objetos, suas características de acesso é listada como não acessível.
Objetos Escalares
Neste caso, não há ambigüidade entre um tipo de objeto e uma instância do objeto: há somente uma instância do objeto para cada tipo de objeto escalar.
Ordenamento Lexicográfico
Um identificador de objeto é uma seqüência de inteiros que refletem uma estrutura hierárquica ou de árvore dos objetos na MIB. Dando a estrutura da árvore de uma MIB, o identificador do objeto de um objeto particular pode ser derivado traçando um caminho da raiz ao objeto.
Devido aos identificadores do objeto serem seqüências de inteiros, eles exibem ordenamento lexicográfico. O ordenamento pode ser gerado por cruzamento da árvore de identificadores de objetos na MIB sendo que o nodo filho de um nodo pai é sempre representado em ordem numeral ascendente. Este ordenamento estende-se ao identificador da instância do objeto, uma vez que um identificador da instância do objeto é também uma seqüência de inteiros. Uma estação de gerenciamento de rede pode não conhecer a composição exata da MIB, que um agente apresenta.
