1) Conceitos Básicos

Consideremos uma LAN com um certo número de dispositivos, cada um com um agente SNMP. Um gerente SNMP pode aprender sobre o tráfego dentro/fora de cada dispositivo mas, com MIB II, não pode aprender facilmente sobre o tráfego como um todo. Tipicamente, um monitor opera numa rede vendo cada pacote da LAN. Pode produzir estatísticas de rede de erros, colisões e outros. Pode armazenar parte de pacotes ou pacotes inteiros para futuras análises.

Para esses propósitos de gerenciamento em ambientes de rede, há de se precisar de um monitor por sub rede. O monitor pode ser um dispositivo stand-alone cujo propósito seja capturar / analisar o tráfego. Em outros casos, as tarefas de monitor são executadas por um dispositivo com outras funções (roteador, servidor, estação de trabalho). Esses monitores precisam se comunicar com uma estação central de gerenciamento de rede.


1.1) Metas

A especificação RMON é uma definição de uma MIB. O efeito, contudo, é para definir funções padrões de monitoração e interfaces para a comunicação entre agentes / gerentes SNMP.

Nem todos os monitores remotos podem ser capaz de alcançar essas metas, mas a especificação dá a base para suportar as metas.

Temos um exemplo abaixo, de uma configuração, mostrando uma rede com cinco sub-redes:



As três sub-redes na porção esquerda/baixo são localizadas no mesmo prédio. As outras duas são em locais remotos. Uma estação gerente com RMON agente/gerente está na LAN central. Em duas das subredes, o agente RMON está em PC's, que podem ser dedicados ou não. Conectado ao backbone de FDDI (interface de dados de fibra-ótica) está o segundo gerente. Finalmente, as funções de agente RMON para a LAN Token-Ring são executadas pelo roteador que conecta a LAN ao resto da Internet.


1.2) Controle de Monitores Remotos

Um monitor remoto pode ser implementado como uma função disponível num sistema ou como um dispositivo dedicado. Com esses recursos dedicados, o monitor é capaz de efetuar funções complexas.

A MIB RMON contém características que suportam controle extensivo da estação de gerenciamento. Dividem-se em duas categorias:

Configuração

Tipicamente, um monitor remoto necessitará ser configurado para coletar dados. A configuração dita o tipo e forma de dados para serem coletados. A MIB é organizada em grupos funcionais. Cada grupo terá uma ou mais tabelas de controle e uma ou mais tabelas de dados. Uma tabela de Controle contém parâmetros que descrevem o dado na tabela de Dados, que é somente para leitura. Assim, a estação gerente seta os parâmetros apropriados para configurar o monitor remoto para coletar os dados desejados. Os parâmetros são setados pela adição de um novo registro na tabela, ou alterando uma existente. Desse modo, funções para serem executadas pelo monitor são definidas e implementadas na tabela. Por exemplo, uma tabela Controle pode conter objetos que especifiquem a origem do dados coletados, tipos de dados, hora/data da coleta etc...

Para modificar qualquer parâmetro na tabela de controle é necessário primeiro invalidar a entrada. Isto causa a deleção daquela entrada e de todos os registros asssociados em tabelas de Dados. A estação gerente pode então criar um novo registro controle com os parâmetros modificados. O mesmo mecanismo é usado para apenas desabilitar uma coleção de dados. Quando um registro da tabela de Controle é apagado, os registros das tabelas de Dados associadas são deletados, e os recursos usados pelas registros são recuperados.

Invocação de Ação

O SNMP providencia mecanismos não específicos para emitir um comando para um agente executar uma ação. SNMP tem apenas capacidade de ler valores de objetos e setar valores de objetos com visão MIB. Contudo, isto é possivel para usar o conjunto de operações SNMP para emitir um comando. Um objeto pode ser usado para representar um comando, assim que uma ação específica é alcançada se o objeto é setado para um valor específico. Um número desses objetos são incluidos na MIB RMON. Em geral, estes objetos representam estados, e uma ação é executada se a estação gerente trocar o estado (pela troca do valor do objeto).


1.3) Múltiplos Gerentes

Como mostrado na figura 1.1, um agente RMON pode ser submetido à múltiplos gerentes. A qualquer tempo/hora acessos concorrentes são permitidos para um recurso, característica potencial para conflitos, resultados inesperados. No caso de agentes RMON compartilhados, as seguintes dificuldades podem surgir:

Para proceder com esses problemas, uma combinação de características de resolução e prevenção é necessária. Ela pretende que uma relativamente simples característica na MIB RMON suporte estes requerimentos. Associado com cada tabela de Controle está um objeto registro que identifica o proprietário de um registro particular da tabela e de funções associadas. O rótulo proprietário pode ser usado das seguintes formas:

A especificação sugere que o rótulo proprietário contenha um ou mais desses: IP, nome da estação gerente, nome do gerente de rede, localização ou telefone.

Apesar do rótulo ser proveitoso, ele é importante para notar que o rótulo não tem ação como uma senha ou mecanismo de controle de acesso.

Se múltiplos gerentes de rede tem acesso à tabela de Controle, muitas eficiências podem ser alcançadas pelo compartilhamento. Quando uma estação gerente quer utilizar uma certa função no monitor, ele precisa verificar a tabela de Controle relevante para ver que função, tem sido definida por outra estação gerente. Neste caso, a estação gerente pode compartilhar a função simplesmente observando os registros de dados read-only associados com a registro de Controle. Contudo, a estação Gerente que seja proprietária de uma tabela de controle pode modificar ou deletar aquele registro a qualquer hora.

Frequentemente, um monitor será configurado com um conjunto padrão de funções que serão setadas quando ele for inicializado. Os registros controle que definem estas funções são propriedades do monitor. Por convenção, cada rótulo relevante é setado com uma string "monitor".


1.4) Gerência de Tabela

Na estrutura SNMP, os procedimentos para adicionar e deletar registros de tabela são obscuros. A especificação RMON inclui um conjunto de convenções textuais e regras procedurais que, enquanto não violam ou modificam a estrutura SNMP, providenciam uma técnica limpa e disciplinada para adição e deleção de registros.

1.4.1) Convenção Textual

Na especificação RMON, dois novos tipos de dados são definidos:

OwnerString::= DisplayString

EntryStatus::= INTEGER{Valid(1), creatRequest(2), underCreation(3), invalid(4)}

Associadas com cada tabela read-write na MIB RMON está um objeto cujo valor indica o proprietário do registro. Este objeto tem o tipo OwnerString.

Também associada à tabela está um objeto cujo valor dá o status do registro que contém a instância do objeto. Este objeto tem o tipo EntryStatus e tem quatro valores possíveis. Objetos deste tipo são usados na criação, modificação e deleção de registros.

Os RFCs 1271 e 1757 se referem a estas definições como convenções textuais. Seu propósito é garantir a especificação.

Estrutura Geral utilizada pelas Tabelas de Controle e Dados na MIB RMON:

exampleTable OBJECT-TYPE

SYNTAX SEQUENCE OF ExampleEntry

ACCESS not-accessible

STATUS mandatory

DESCRIPTION "a table containing a list of table entries, or rows."

::= {egroup1}

exampleEntry OBJECT-TYPE

SYNTAX ExampleEntry

ACCESS not-accessible

STATUS mandatory

DRESCRIPTION "Defines the conceptual row for example table."

INDEX {exampleIndex}

::= {exampleTable 1}

ExampleEntry::= SEQUENCE{ exampleIndex INTEGER (0..65535),

exampleParameter Counter,

exampleOwner OwnerString,

exampleStatus INTEGER }

ExampleIndex OBJECT-TYPE

SYNTAX INTEGER (0..65535)

ACCESS read-only

STATUS mandatory

DRESCRIPTION "the value of this object uniquely identifies this example entry"

::= {exampleEntry 1}

exampleParameter OBJECT-TYPE

SYNTAX integer

ACCESS read-write

STATUS mandatory

DRESCRIPTION "the value characterizes data table rows associate with this entry"

::= {exampleEntry 2}

exampleOwner OBJECT-TYPE

SYNTAX OwnerString

ACCESS read-write

STATUS mandatory

DRESCRIPTION "the entity that configured this entry using the resources"

::= {exampleEntry 3}

exampleStatus OBJECT-TYPE

SYNTAX EntryStatus

ACCESS read-write

STATUS mandatory

DRESCRIPTION "the status of this example entry"

::= {exampleEntry 4}

1.4.2) Adição de Registro

Um SetRequest PDU emitido inclui uma lista de objetos tabulares identificados na tabela. Cada objeto é um identificador de instância, consistindo do identificador do objeto seguido pelo valor do índice ou índices para aquela tabela.

Quando um agente recebe uma requisição ele precisa checar o conjunto de parâmetros requisitados para determinar se o que se quer é permitido, dadas as restrições definidas no RMON, bem com qualquer restrição de implementação. Se a adição não é possível, um GetResponse com erro é retornado. O campo de erro indica o primeiro campo na lista de variáveis cuja requisição foi invalidada.

A MIB RMON suporta um mecanismo de guarda com o problema atribuído pela tentativa de múltiplas adições de múltiplas estações gerente. O problema ocorre se duas ou mais estações tentam criar um registro com os mesmos parâmetros. Para arbitrar este conflito, existe uma máquina de estados dentro da estrutura MIB definida pelo objeto, fazendo um controle efetivo de construção.

1.4.3) Modificação ou Deleção de Registro

Um registro é deletado fazendo a setagem do valor de status para inválido. O proprietário pode então deletá-la emitindo o SetRequest PDU apropriado. Um registro pode ser modificado fazendo antes sua invalidação e então provendo novos valores.