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.
Operação OFF-line: Pode ser necessário para
limitar ou parar a rotina de polling de um monitor. Polling limitados reduzem
custos de comunicação, especialmente onde linhas dial-up podem
ser usadas. Polling pode cessar se ocorre uma falha na
comunicação ou no gerente. Em geral o monitor devia coletar
faltas, performances e informações de configuração
continuamente, mesmo não sendo alvo de pesquisa (poll) de um gerente. O
monitor continua a acumular estatísticas que podem ser recuperadas
depois pelo gerente. O monitor pode também notificar a
estação de gerenciamento se eventos excepcionais ocorrerem.
Monitoramento preemptivo: Se o monitor tiver recursos suficientes,
pode executar continuamente diagnósticos e logar performance da rede. Em
uma falha na rede, pode notificar a estação gerente da falha e
prover informações proveitosas no diagnóstico da falha.
Detecção de Problemas e Relatório: O monitor pode
passivamente reconhecer certas condições de erro e outros, como
congestionamento, no tráfego observado. Quando uma
condição configurada ocorrer, pode logar e tentar notificar a
estação gerente.
Análise de Dados: O monitor pode executar análises
específicas após coletados os dados na subrede. Por exemplo, pode
determinar que Host gera a maior parte do tráfego ou erros na subrede.
Múltiplos gerentes: Uma configuração de rede pode
ter mais que uma estação gerente para gerar confiança,
executar funções diferentes e prover capacidades de
gerência para unidades diferentes na organização.
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:
- Requisições concorrentes podem exceder a capacidade do monitor
para fornecer estes recursos.
- Uma estação gerente pode capturar e ocupar recursos de monitor
por um longo período de tempo, prevenindo seu uso por outras
funções gerente desejadas por outras estações
gerentes.
- Recursos podem ser designados para uma estação gerente que caiu
sem liberar os recursos.
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:
- Uma estação gerente pode reconhecer recursos próprios.
- Um operador pode identificar a estação gerente que seja
proprietária de um recurso em particular ou função e
negociar para serem livres para todos.
- Um operador pode ter autoridade para liberar recursos que outro operador
tenha reservado.
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.
