RMON. Introdução Criado pelos mesmos grupos que desenvolveram o TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento de redes cuja sigla representa

RMON

Introdução• Criado pelos mesmos grupos que desenvolveram o

TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento de redes cuja sigla representa Remote Network Monitoring MIB. Primeiramente, desenvolveu-se o padrão SNMP; somente depois pensou-se no RMON.

• Simple Network Management Protocol, ou SNMP, é um protocolo de gerenciamento realmente simples: a única informação que se tem através de um alerta SNMP é que existe um problema em um ponto da rede. Os alertas do SNMP padrão notificam um problema somente quando ele já atingiu uma condição extrema suficiente a ponto de comprometer a comunicação na rede como um todo.

Introdução• Ao contrário do que se pode imaginar, o SNMP não é capaz de definir

o problema, nem sua gravidade; não fornece, tampouco, recursos para uma investigação das causas desse problema. O diagnóstico do problema é uma tarefa do administrador da rede. Assim, o SNMP é simplesmente um alerta para uma condição extrema da rede.

• O comitê do IETF decidiu que, para promover uma maior e melhor expansão das tecnologias de rede, era necessário um padrão de gerenciamento de redes mais sofisticado. As principais características do novo padrão, o RMON, seriam: interoperabilidade independentemente de fabricante; capacidade de fornecer informações precisas a respeito das causas de falha no funcionamento normal da rede, assim como da severidade dessa falha; finalmente, o novo padrão deveria oferecer ferramentas adequadas para diagnóstico da rede. Além destas características, o padrão deveria oferecer um mecanismo proativo para alertar o administrador dos eventuais problemas da rede, além de métodos automáticos capazes de coletar dados a respeito desses problemas.

Introdução• Ao contrário do que se pode imaginar, o SNMP não é capaz de definir

o problema, nem sua gravidade; não fornece, tampouco, recursos para uma investigação das causas desse problema. O diagnóstico do problema é uma tarefa do administrador da rede. Assim, o SNMP é simplesmente um alerta para uma condição extrema da rede.

• O comitê do IETF decidiu que, para promover uma maior e melhor expansão das tecnologias de rede, era necessário um padrão de gerenciamento de redes mais sofisticado. As principais características do novo padrão, o RMON, seriam: interoperabilidade independentemente de fabricante; capacidade de fornecer informações precisas a respeito das causas de falha no funcionamento normal da rede, assim como da severidade dessa falha; finalmente, o novo padrão deveria oferecer ferramentas adequadas para diagnóstico da rede. Além destas características, o padrão deveria oferecer um mecanismo proativo para alertar o administrador dos eventuais problemas da rede, além de métodos automáticos capazes de coletar dados a respeito desses problemas.

Introdução

• Assim, o RMON tornou-se um padrão por volta de 1990. O RMON II foi publicado recentemente para estender as capacidades do RMON, cujo padrão está disponível nas RFCs 1757 e 1531 e apresentam padrões para redes Ethernet e Token Ring.

Uma visão geral

• As estatísticas indicam: enquanto apenas 30% dos custos de uma rede estão diretamente associados à aquisição de hardware, os 70% restantes dizem respeito à manutenção e ao suporte dessa rede.

• No momento da aquisição dos equipamentos de uma rede, o elemento determinante na escolha da melhor opção é, via de regra, o custo. Uma vez iniciado o processo de expansão dessa rede, os verdadeiros custos se manifestam. Neste momento, o departamento administrativo irá questionar: e o gerenciamento da rede?

Uma visão geral

• As estatísticas indicam: enquanto apenas 30% dos custos de uma rede estão diretamente associados à aquisição de hardware, os 70% restantes dizem respeito à manutenção e ao suporte dessa rede.

• No momento da aquisição dos equipamentos de uma rede, o elemento determinante na escolha da melhor opção é, via de regra, o custo. Uma vez iniciado o processo de expansão dessa rede, os verdadeiros custos se manifestam. Neste momento, o departamento administrativo irá questionar: e o gerenciamento da rede?

Uma visão geral

• Alguns exemplos de recursos oferecidos por ferramentas de gerenciamento de redes são:– Dados de interoperação das redes; – Alertas de problemas; – Aviso antecipado de problemas; – Captura automática de dados; – Gráficos de utilização de hosts em tempo real; – Gráficos de eventos da rede.

Os custos de uma rede

• Como indicado anteriormente, os custos relacionados à aquisição de equipamentos constituem em torno de 30% do custo total da rede; os 70% restantes estão associados aos custos de manutenção e suporte da rede. A fim de reduzir os custos da rede, podem ser destacadas algumas políticas:


• Proteção do Investimento – Evitar a aquisição de equipamentos com pequeno ou

nenhum grau de escalabilidade. Procurar adquirir produtos baseados numa mesma infra-estrutura e que permitam atualizações naturalmente, sem a necessidade de troca do equipamento.


• Aumento da Disponibilidade – Quanto mais tempo a rede estiver no ar, tanto maior

será sua capacidade de produção. A disponibilidade depende de hardware tanto quanto de software. Do ponto de vista de hardware, a rede deverá utilizar dispositivos com sistemas de redundância em todos os níveis, desde suprimentos de energia, até HDs, processadores e up-links; do ponto de vista de software, deverá permitir o aviso automático de condições extremas, paging de pessoal e captura automática de dados em ocasião de erros. Enfim, quanto maior a capacidade da rede de manter-se no ar, em condições normais de funcionamento, tanto maior será sua capacidade de produzir.


• Manutenção Simplificada – A rede deverá permitir o rápido isolamento do problema. O

sistema de gerenciamento deverá identificar o problema, sua origem, e a abordagem mais indicada para resolvê-lo.

– O diagnóstico remoto deverá ser facilitado através da integração das ferramentas de diagnóstico da rede em seus componentes. O sistema de gerenciamento deverá permitir a notificação antecipada dos problemas da rede antes mesmo que eles ocorram. Isto deverá ser realizado através da configuração de graus de tolerância para os vários elementos da rede. Desta forma, cria-se um novo paradigma de gerenciamento, onde o suporte da rede é realizado de forma proativa, ao invés de reativa.


• Rápida Resolução de Problemas – Utilizar, sempre que possível, equipamentos de rede

inteligentes, capazes de coletar dados sobre o seu funcionamento e atualizarem suas configurações remotamente, via software. Dessa forma, o sistema de gerenciamento remoto poderá dispor dos dados registrados por um determinado equipamento para otimizar seu desempenho ao longo do tempo.


• Todos os itens acima justificam a adoção de uma solução de gerência de redes, particularmente, um sistema com características como as do RMON. Para entender, portanto, como os custos de operação de redes podem ser reduzidos através da utilização do RMON, é necessário compreender sua arquitetura. Somente com essa compreensão será possível avaliar quanto pode ser economizado em tempo e dinheiro na operação de uma rede corporativa.

A Arquitetura RMON

• O RMON é um padrão IETF. Portanto, não é uma solução proprietária. Na realidade, um só fabricante dificilmente irá implementar a solução RMON completa. No cenário do gerenciamento RMON, os equipamentos de rede carregam MIBs RMON, a rede transporta os dados, um sistema de gerenciamento aceita alarmes e notifica usuários, e uma ferramenta de análise RMON interage com os grupos RMON e seus dados.

• Dentre os protocolos de gerenciamento, o RMON é, certamente, dos primeiros a permitir o gerenciamento proativo. Talvez seja esta a grande vantagem do mesmo em relação às outras arquiteturas de gerenciamento. O trabalho de gerenciamento é simplificado e a resolução dos problemas facilitada. Assim, aumenta a disponibilidade da rede e caem os custos de manutenção de forma significativa.

A Arquitetura RMON

• A contrapartida dessa enorme vantagem é que o RMON é uma extensão de protocolo que atua apenas até a camada MAC. A capacidade de gerenciamento das camadas superiores é que permite a um protocolo o monitoramento ponto-a-ponto do tráfego corporativo (ou seja, além dos segmentos de rede), e do tráfego específico à camada de aplicação. Essa capacidade é implementada pelo RMON-II.

Exemplo: Gerenciando colisões numa Rede ETHERNET

• Considere uma rede Ethernet em que o nível de saturação de colisões aceitável é de 60%. Através de uma estação de gerenciamento, o adminsitrador da rede configura, no dispositivo de gerenciamento (monitor) da rede, o limite de saturação de colisões para 40%, por exemplo. Se, num dado momento, a rede exceder esse valor, uma armadilha (trap) RMON será disparada e enviada ao sistema de gerenciamento. O sistema de gerenciamento será responsável por exibir o mapa de alerta e os dados recebidos do monitor, além de notificar o administrador da rede do recebimento desse alerta (através de um pager, por exemplo). O alerta poderá, também, iniciar um processo de filtragem e captura de dados para análise posterior.

Exemplo: Gerenciando colisões numa Rede ETHERNET

• Como foi ilustrado, a configuração de alarmes poderá garantir a operação da rede dentro dos níveis definidos pelo administrador. No momento em que um alarme é emitido, é possível identificar e corrigir as causas da condição de erro através da análise dos dados coletados pelo monitor antes e após o disparo do alarme. Esta forma de resolução de problemas, antes que estes atinjam níveis intoleráveis, é, certamente, o grande diferencial do RMON.

O padrão RMON: RFC 1757

• A RFC 1757 define o padrão RMON de gerenciamento. Segundo a RFC, o RMON não é uma pilha de protocolos, nem sequer um protocolo por si só. Na realidade, trata-se de uma extensão de MIB, Management Information Base, para ser utilizada com protocolos de gerenciamento de rede em internets baseadas em TCP/IP.

RMON

RMON

• Características– Usado em LANs e WANs– Uso de Probes - monitores das redes que trabalham

em modo promíscuo verificando cada pacote da LAN– Monitores:

• Comunicam-se com uma estação central de gerenciamento de rede

• Podem produzir estatísticas de erros da rede, colisões e outros

• Podem armazenar partes dos pacotes ou pacotes inteiros para análises posteriores

VISÃO GERAL

• Os dispositivos de gerenciamento remoto de redes, normalmente chamados de monitores ou sondas (probes), são instrumentos cuja existência é dirigida exclusivamente ao gerenciamento de redes. Geralmente, são independentes (standalone) e direcionam boa parte de seus recursos internos ao gerenciamento da rede a qual estão conectados.

• Uma organização pode empregar vários destes dispositivos para o gerenciamento de sua rede um por segmento. Adicionalmente, os monitores podem ser utilizados para que um provedor de serviços de gerenciamento de rede possa acessar uma rede cliente, normalmente separada geograficamente.

VISÃO GERAL

• Os objetos definidos na RFC 1757 são objetos de interface entre agentes RMON e aplicações de gerenciamento RMON. Ainda que a maioria desses objetos sirva a qualquer tipo de gerenciamento de redes, alguns são específicos às redes Ethernet. A estrutura desta MIB permite que outros objetos sejam desenvolvidos para outros tipos de redes. Há uma expectativa de que futuras versões da RFC 1757 ou outros documentos definam extensões para outros tipos de redes, como FDDI ou Token Ring.

OBJETIVOS

• O padrão RMON foi desenvolvido no intuito de resolver questões que outros protocolos de gerenciamento não eram capazes. Com base nestas questões, a RFC 1757 define objetivos gerenciais que o padrão RMON deve observar:

OBJETIVOS

• Operação Off-line – Existem situações em que uma estação de gerenciamento não

estará em contato contínuo com seus dispositivos de gerenciamento remoto. Esta situação pode ocorrer como conseqüência de projeto, a fim de que se reduzam os custos de comunicação, ou por falha da rede, quando a comunicação entre a estação de gerenciamento e o monitor fica comprometida em sua qualidade.

– Por esta razão, a MIB RMON permite que um monitor seja configurado para realizar suas atividades de diagnóstico e coleta de dados estatísticos continuamente, mesmo quando a comunicação com a estação de gerenciamento seja impossível ou ineficiente. O monitor poderá então comunicar-se como a estação de gerenciamento quando uma condição excepcional ocorrer.

OBJETIVOS

• Operação Off-line– Assim, mesmo em circunstâncias em que a comunicação

entre monitor e estação de gerenciamento não é contínua, as informações de falha, desempenho e configuração podem ser acumuladas de forma continua, e transmitidas à estação de gerenciamento conveniente e eficientemente quando necessário.

OBJETIVOS

Monitoramento Proativo – Dados os recursos disponíveis no monitor, é

normalmente desejável e potencialmente útil que ele execute rotinas de diagnóstico de forma contínua e que acumule os dados de desempenho da rede. O monitor estará sempre disponível no início de uma falha; assim, ele poderá notificar a estação de gerenciamento da falha, assim como armazenar informações estatísticas a seu respeito. Esta informação estatística poderá ser analisada pela estação de gerenciamento numa tentativa de diagnosticar as causas do problema.

OBJETIVOS

• Detecção e Notificação de Problemas – O monitor pode ser configurado para reconhecer

condições, que, normalmente, são de erro e verificar pelas mesmas continuamente. No advento de uma destas condições, o evento pode ser registrado e as estações de gerenciamento notificadas de várias formas.

OBJETIVOS

• Valor Agregado aos Dados – Considerando o fato de que os dispositivos de

gerenciamento remoto representam recursos dedicados exclusivamente a funções de gerenciamento, e considerando também que os mesmos localizam-se diretamente nas porções monitoradas da rede, pode-se dizer que estes dispositivos permitem a agregação de valor aos dados coletados. Por exemplo, indicando quais os hosts que geram a maior quantidade de tráfego ou erros, um dispositivo pode oferecer (à estação de gerenciamento) informações preciosas para a resolução de toda uma classe de problemas.

OBJETIVOS

• Gerenciamento Múltiplo – Uma organização pode ter mais de uma estação de

gerenciamento para as várias unidades da empresa, para funções distintas, ou como tentativa de proporcionar recuperação em caso de falha (crash recovery). Como tais ambientes são comuns na prática, um dispositivo de gerenciamento de rede remoto deverá ser capaz de lidar com múltiplas estações de gerenciamento concorrendo para a utilização de seus recursos.

CONVENÇÕES • Dois novos tipos de dados foram introduzidos como

convenções textuais nesta MIB. Essas convenções facilitam a compreensão da especificação e podem servir como base para comparação com outras especificações quando apropriado. A introdução dessas convenções, convém esclarecer, não tem qualquer efeito sobre a sintaxe ou semântica dos objetos gerenciados. Seu uso é um artifício explicativo do método utilizado. Objetos definidos em função de um desses métodos são codificados por meio das regras que definem o tipo de dado primitivo. Assim, fica claro que a utilização destes campos dá-se por conveniência aos leitores e desenvolvedores, com o claro objetivo de proporcionar documentos MIB claros, concisos e não ambíguos. Os dois novos tipos de dados são: OwnerString e EntryStatus.

MIB RMON

internet (1)

private(4)experimental (3)mgmt (2)directory (1) security(5) snmpV2(6)

mib-2 (1)

system (1) rmon (16)...

MIB RMON

RMON (mib-2 16)

Statistics (1)

History (2)

Alarm (3)

Host (4)

HostTopN (5)

Matrix(6)

Filter (7)

Capture (8)

Event (9)

TokenRing (10)

A estrutura da MIB

• A extensão RMON da MIB consiste de conjunto de definições de objetos; cada um destes objetos é classificado segundo o grupo a que foi associado. Eis os grupos definidos pela MIB:

– Estatísticas Ethernet; – Histórico de Controle; – Histórico Ethernet; – Alarme; – Host; – HostTopN; – Matriz; – Filtro; – Captura de Pacotes; – Evento.

A estrutura da MIB

• Estes grupos são as unidades básicas de conformidade. Se um dispositivo de monitoramento remoto implementa um grupo, deverá implementar todos os objetos definidos naquele grupo.

• Todos os grupos nesta MIB são opcionais. A implementação da mesma exige a implementação do grupo de sistema e interfaces definidos na MIB-II. E esta, por sua vez, poderá exigir a implementação de grupos adicionais.

• Estes grupos são definidos para que exista um mecanismo adequado para a identificação dos objetos no ambiente de gerenciamento, e para que os sistemas de gerenciamento implementem adequadamente o conjunto de objetos necessários ao funcionamento do esquema.

A estrutura da MIB

• Grupo de Estatísticas Ethernet – Este grupo contém as estatísticas levantadas por um

monitor para cada interface Ethernet do dispositivo gerenciado. Ele servirá de modelo para a implementação de grupos para outros tipos de rede, como Token Ring e FDDI. Consiste apenas do etherStatsTable.

A estrutura da MIB

• Grupo de Histórico de Controle – O controle da amostragem estatística dos dados de

vários tipos de rede é a função deste grupo. Ele consiste apenas do historyControlTable.

• Grupo de Histórico Ethernet – Este grupo registra amostras periódicas da rede

Ethernet e as armazena para análise posterior. Outros grupos deverão ser definidos para outras redes como Token Ring e FDDI. Consiste apenas do etherHistoryTable.

A estrutura da MIB

• Grupo de Alarme – O grupo de alarme realiza amostragens estatísticas das

variáveis do monitor e as compara aos limites previamente configurados. Se uma variável monitorada ultrapassa o limite estabelecido, um evento é gerado. Este grupo consiste do alarmTable e requer a implementação do grupo de evento.

• Grupo de Host – O grupo de host contém dados estatísticos a respeito de cada

um dos hosts descobertos na rede. O grupo descobre os hosts na rede através da captura de pacotes recebidos promiscuamente da rede. Com estes pacotes, monta uma lista dos endereços MAC da origem e destino. Este grupo consiste de três objetos: hostControlTable, hostTable e hostTimeTable.

A estrutura da MIB

• Grupo de HostTopN – A função deste grupo é preparar relatórios descritivos

dos hosts que ocupam o topo da lista de uma determinada estatística. As estatísticas disponíveis são amostras de uma das estatísticas padrão num intervalo de tempo especificado pela estação de gerenciamento. Essas estatísticas são, na realidade, taxas. A estação de gerenciamento também deverá determinar a quantidade de hosts a ser analisada. Os objetos deste grupo são: hostTopNControlTable e hostTopNTable. Este grupo requer a implementação do grupo de host.

A estrutura da MIB

• Grupo de Matriz – O grupo de matriz armazena dados das conversas

entre conjuntos de dois endereços. Quando um dispositivo detecta uma nova conversa, ele cria uma nova entrada em suas tabelas. O grupo consiste de: matrixControlTable, matrixSDTable e matrixDSTable.

• Grupo de Filtro – Este grupo identifica pacotes que satisfazem critérios

estabelecidos através de uma equação de filtragem. Os pacotes que satisfazem determinados critérios formam um fluxo de dados que pode gerar eventos ou ser capturado. O grupo consiste de dois objetos: filterTable e channelTable.

A estrutura da MIB

• Grupo de Captura de Pacotes – Permitir que pacotes sejam capturados após

passarem por determinado canal ou filtro é a função deste grupo. Ele consiste de dois objetos: bufferControlTable e captureBufferTable. Este grupo requer a implementação do grupo de filtro.

• Grupo de Evento – O grupo de evento controla a geração e notificação

de eventos de um determinado dispositivo. Consiste do eventTable e do logTable.

Controle dos dispositivos RMON

• Devido a natureza complexa das funções dos dispositivos de gerenciamento, normalmente, faz-se necessária uma configuração prévia. Em muitos casos, as funções necessitam de parâmetros para que uma coleta de dados seja realizada adequadamente. A operação só pode ser realizada após estes parâmetros estarem devidamente configurados.

• Vários grupos funcionais definidos nesta MIB têm uma ou mais tabelas adequadas à configuração de parâmetros de controle, e uma ou mais tabelas de dados para o armazenamento dos resultados de uma determinada operação.

Controle dos dispositivos RMON• As tabelas de controle são, por natureza, do tipo leitura

e escrita; as tabelas de dados, por sua vez, são tipicamente apenas de leitura. Devido ao fato de que os parâmetros nas tabelas de controle descrevem os dados nas tabelas de dados, muitos deles somente podem ser alterados quando forem inválidos. Isto significa que, para alterar um determinado parâmetro de controle é necessário invalidá-lo. Uma vez inválido, o parâmetro é removido da tabela de controle, juntamente com todos os dados associados nas tabelas de dados. Somente então, cria-se uma nova entrada na tabela de controle para o parâmetro em questão. Observe que a exclusão de uma entrada na tabela de controle também serve como um mecanismo para a recuperação dos recursos associados àqueles dados.

Controle dos dispositivos RMON

• Alguns objetos nesta MIB fornecem mecanismos para a execução de uma ação no dispositivo remoto de gerenciamento. A ação pode ser realizada em conseqüência à alteração do estado do objeto. Para os objetos definidos nesta MIB, uma solicitação para armazenar um valor no objeto igual ao valor atualmente armazenado será ignorada pelo mesmo.

• Para permitir o controle por múltiplos gerenciadores, os recursos devem ser compartilhados por vários deles. tratam-se, tipicamente, da memória e dos recursos computacionais que uma função necessita.

Compartilhamento de recursos entre múltiplos gerenciadores

• Quando mais de uma estação deseja utilizar funções que competem por uma quantidade finita de recursos no dispositivo de gerenciamento, um método para facilitar o compartilhamento de seus recursos é necessário. Conflitos em potencial incluem:– Duas estações necessitam utilizar simultaneamente recursos

que, somados, excedem a capacidade do dispositivo. – Um estação de gerenciamento necessita utilizar uma

quantidade significativa de recursos por um período prolongado. – Uma estação de gerenciamento aloca recursos e falha,

deixando os recursos alocados, impedindo que outras estações possam utilizá-los.


• Existe um mecanismo, definido nesta MIB, disponível para cada função inicializada a partir de uma estação de gerenciamento, que evita esse tipo de conflito e ajuda a resolvê-los quando eles ocorrem. Cada função tem um rótulo identificando o iniciador (dono) da função. Este identificador é preenchido pelo iniciador e permite que:– Uma estação reconhece os recursos alocados para si e que não são

mais necessários.

– Um operador pode identificar o dono de um determinado recurso e negociar para que seja liberado.

– Um operador pode, unilateralmente, resolver liberar recursos alocados por um outro operador.

– No momento da inicialização, uma estação de gerenciamento pode reconhecer recursos previamente reservados. Com esta informação, a estação poderá liberar recursos não mais necessários.


• Estações de gerenciamento devem suportar qualquer formato do OwnerString determinado pela política local da empresa. Como sugestão, o identificador deverá conter um ou mais de: endereço IP, nome da estação de gerenciamento, nome, telefone ou localização do operador da estação de gerenciamento. Esta informação permitirá aos usuários o compartilhamento mais eficiente dos recursos.

• Normalmente, existe certa funcionalidade padrão que o dispositivo ou administrador deseja configurar. Os recursos alocados para estas funcionalidades serão de longa duração e estarão associados ao próprio dispositivo ou administrador. Neste caso, ou o dispositivo ou o administrador deverá definir o OwnerString com um string iniciando com monitor. Modificações indiscriminadas dessas configurações são desencorajadas. Com efeito, uma estação de gerenciamento somente deverá alterar estes objetos com autorização do administrador do dispositivo.


• Os recursos num monitor são normalmente escassos e alocados quando uma linha é acrescentada a uma tabela de controle por uma aplicação. Como várias aplicações podem utilizar um determinado monitor simultaneamente, alocação indiscriminada dos recursos de um monitor poderá causar falta de recursos no mesmo.

• Quando uma estação de gerenciamento deseja utilizar uma função de um monitor, encoraja-se que, primeiramente, ela investigue a tabela de controle daquela função em busca de uma instância com parâmetros semelhantes para que possa compartilhar. Esta situação é particularmente indicada para as funções pertencentes ao próprio monitor, que tendem a sofrer poucas alterações. Se uma estação de gerenciamento decide compartilhar uma instância pertencente a uma segunda estação de gerenciamento, deverá levar em conta o fato de que a estação dona da instância poderá modificá-la ou exclui-la inadvertidamente, a qualquer momento.


• Deve-se destacar o fato de que uma aplicação poderá confiar nas instâncias pertencentes ao monitor pois estas deverão ser alteradas raramente. Instâncias pertencentes à propria aplicação de gerenciamento são menos persistentes que as anteriores e menos confiáveis. Instâncias pertencentes a outras aplicações são as menos confiáveis, pois podem ser alteradas a qualquer momento pela aplicação, sem advertência prévia.

Inclusão de linhas entre múltiplos gerenciadores

• A inclusão de linhas nas tabelas definidas por esta MIB deverá ser realizada pelo método descrito na RFC 1212. Nesta MIB, linhas são incluídas nas tabelas para configurar uma determinada função. Esta configuração normalmente envolve a definição de parâmetros que controlam a operação da função.

• O agente deverá checar esses parâmetros para garantir que são apropriados uma vez observadas as restrições definidas e outras específicas à implementação, como a falta de recursos. Na implementação desta MIB, pode-se definir dois momentos para notificar a estação de gerenciamento de que os parâmetros são inválidos:– Quando a estação de gerenciamento altera cada parâmetro. – Quando a estação define o EntryStatus do objeto como válido.


• Se o segundo for o escolhido, não ficará claro à estação de gerenciamento qual dos parâmetros de configuração estão inválidos, causando a emissão do erro badValue. Assim, sempre que possível, a implementação da MIB deverá observar a primeira opção em detrimento da segunda, por fornecer maiores detalhes a respeito do parâmetro inválido.

• Um problema pode surgir quando várias estações de gerenciamento tentarem alterar um parâmetro de configuração simultaneamente através do SNMP.


• Quando o processo envolve a criação de uma entrada numa tabela de controle, os gerenciadores podem colidir, tentando criar a mesma entrada. Como proteção contra esta situação, cada entrada na tabela de controle tem um objeto para o controle de estado da entrada com uma semântica especial que auxilia na resolução de conflitos entre gerenciadores. Assim, o mecanismo de criação de uma entrada na tabela sempre irá tentar criar o objeto de controle de estado. Se ele já existir, um erro é retornado e a tabela não é alterada. Pois, quando vários gerenciadores tentam criar a mesma entrada conceitual na tabela, apenas o primeiro será bem sucedido; os demais receberão um erro.


• Quando um gerenciador deseja criar uma nova entrada numa tabela de controle, deverá escolher um índice para aquela entrada. Esta escolha poderá ser realizada de várias formas, de preferência visando a minimização da possibilidade de repetição de índices utilizados por outros gerenciadores. Se o índice já existe, o mecanismo descrito anteriormente cuidará para que as colisões sejam evitadas.

• Como algumas tabelas definidas nesta MIB referenciam outras tabelas da mesma, ao incluir ou excluir entradas numa determinada tabela, é permitida a existência de referências pendentes ou não resolvidas. Não está definida qualquer ordem para inclusão ou exclusão de entradas nessas tabelas.

Conclusão

• O RMON é uma arquitetura definida pela RFC 1757 para o gerenciamento proativo de redes. Funciona sobre a pilha TCP/IP, integrado ao SNMP. Na realidade, o padrão RMON é uma MIB definida para permitir a implementação de um esquema proativo de gerenciamento, baseado na definição de limites de tolerância para a rede.

• Outras RFCs estendem as funções RMON definindo padrões de gerenciamento para elementos não cobertos pela RFC 1757. Na sua maioria, e assim como o próprio padrão RMON, definem extensões de MIB para realizar tarefas específicas.

Conclusão

• Como ilustração do grande apelo comercial do RMON, estimativas indicavam vendas de equipamentos RMON na ordem de 1 bilhão de dólares para o ano de 1997. Este é um indicativo bastante forte da força deste padrão e leva a crer que os esforços no sentido de estender as funcionalidades do mesmo serão de grande importância na evolução dos sistemas de gerenciamento de rede.

• O RMON-II, sucessor natural do RMON, realiza um mapeamento de todos os grupos RMON nos mais populares protocolos de rede como IP, IPX, DECnet, AppleTalk, Vines e protocolos OSI em geral. Oferece, além disso, a capacidade de gerenciamento em qualquer um dos 7 níveis da camada OSI, além de permitir a administração de aplicativos distribuídos como Lotus Notes e Sybase SQL.

Conclusão

• Espera-se, da evolução do RMON, o suporte avançado à arquitetura cliente/servidor, permitindo, por exemplo, a utilização de monitores como proxys de gerenciamento SNMP. Nessa estrutura, o dispositivo atuando como proxy seria responsável pelo gerenciamento dos equipamentos localizados na sua rede. Haveria uma redução no tráfego SNMP das aplicações de gerenciamento, aumentando a disponibilidade da rede como um todo. Outra característica desejável seria o suporte a topologias avançadas, com backbones de alta velocidade e redes virtuais (VLANs).

Conclusão

• A arquitetura RMON realizou uma quebra no paradigma de gerenciamento de redes. Enquanto arquiteturas concorrentes atuavam de forma reativa no surgimento de problemas na rede, o RMON define um modelo proativo de atuação, permitindo que a rede permaneça mais tempo no ar, garantindo um melhor desempenho como um todo e minimizando os tempos e custos de manutenção em geral. O RMON, apesar de contribuir decisivamente para a evolução do paradigma de gerenciamento, não é a solução definitiva.

• Com a constante evolução das tecnologias de rede, novas soluções de gerenciamento surgirão e substituirão os padrões existentes. O que fica evidente, entretanto, é que RMON é um marco para a gerência de redes: os novos protocolos certamente irão buscar no RMON a inspiração para a implementação de algumas de suas características.

Referências bibliográficas

• Waldbusser, S. "RFC 1757 - Remote Network Monitoring Management Information Base."

• NetScout System, Inc. "RMON, RMON2, and Beyond."

• STALLINGS, William. Snmp, Snmpv2, Snmpv3 and Rmon 1 and 2. Addison-Wesley, 3rd edition, 1999.

RMON2

RMON2• Mesmo sendo RMON um passo significante no

monitoramento remoto de LANs e WANs, o uso da versão 1 revelou algumas desvantagens - fraquezas que foram consertadas em RMON2.

• Listamos, abaixo, alguns exemplos:

– Monitoramento de tráfego ampliado: Análises tradicionais baseadas em RMON oferecem ao gerente de rede um poderoso sistema de correção de erros e uma capacidade de monitorar um segmento LAN no nível MAC, mas não conseguem enxergar o tráfego quando este ultrapassa as barreiras do roteamento. Com RMON2, gerentes de rede serão capazes de ver o tráfego desde a camada 3 até a 7 do modelo OSI (Open Systems Interconnect), Isto significa que gerentes serão capazes de ver como flui o tráfego de rede em cada um dos 7 níveis do modelo OSI - uma capacidade que terá um impacto significante no controle e resoluçao de erros em ambientes cliente/servidor. Figura 1 nos mostra o nível de visibilidade que RMON e RMON2 provêem dentro de um segmento LAN ou de uma rede em cada uma das camadas do OSI.

Limitações supridas pelo RMON2

– Maior confiança no fornecedor: atualmente, para que algum produto seja "baseado em RMON" ele necessita apenas implementar um dos grupos RMON. Com isso, as capacidades RMON podem variar drasticamente de um fornecedor para outro, dependendo do número de grupos RMON MIB que o produto suporta. RMON2 requerirá que produtos implementem-na mais amplamente para que possa ser considerado "baseado em RMON2".

– Correlação com a Camada Física: monitores baseados em RMON coletam estatísticas no nível 2, a camada Data Link do modelo OSI. Esta camada se concentra primordialmente com a formação dos pacotes: endereçamento e entrega. Embora esse tipo de informação seja muito útil para a resolução de problemas, não se tem nenhuma visão do nível físico. RMON2 tem a habilidade de relacionar informação de porta ou cabeamento na estação final, aumentando incrivelmente a visibilidade da rede.

Limitações supridas pelo RMON2

– História Completa: com RMON2, qualquer objeto MIB pode ser localmente rastreado e gravado em um log histórico.

• Os benefícios do RMON estendem a monitoração aos mais altos níveis das camadas do protocolo. Enquanto RMON somente provê estatísticas de tráfego na camada MAC do protocolo, RMON2 provê um discernimento das estatísticas de tráfego bem maior, especificando o protocolo e as aplicações que geraram aquele tráfego. Este conhecimento é de vital importância nos dias de hoje. Estender a visão do segmento RMON ampliando àquela fornecida pelo RMON2 faz com que gerentes de rede tenham mais informações e maior conhecimento para gerenciar, corrigir os erros e monitorar redes cada vez mais complexas. Como resultado, RMON2 permitirá a análise cliente/servidor de uma nova classe inteira de aplicações; monitoramento e projeto inter-rede; e registro nas camadas de rede e aplicação.

Estrutura da RMON2-MIB

• Os objetos definidos em RMON2-MIB são arranjados nos seguintes grupos: – protocol directory (protocolDir) – protocol distribution (protocolDist) – address mapping (addressMap) – network layer host (nlHost) – network layer matrix (nlMatrix) – application layer host (alHost) – application layer matrix (alMatrix) – user history (usrHistory) – probe configuration (probeConfig)

Objetos RMON e RMON2

Estrutura da RMON2-MIB

• Os 9 grupos apresentados formam a base de toda RMON2-MIB. Se um dispositivo de gerenciamento remoto implementa um grupo, então ele deve implementar todos os objetos naquele grupo. Por exemplo, um agente que implementa o grupo network layer matrix deve implementar o nlMatrixSDTable e o nlMatrixDSTable.

• Implementações desta MIB devem também implementar os grupos system e interfaces da MIB-II. Pode-se, sem prejuízo nenhum, implementar outros grupos que sejam necessários.

• Os grupos de RMON2-MIB são definidos para prover um significado no assinalamento dos identificadores dos objetos e para fornecer um método para que os agentes saibam quais objetos eles devem implementar.

Os 9 Grupos da RMON2-MIB

• Grupo Protocol Directory (protocolDir): Lista os protocolos que o probe tem a capacidade de monitorar e permite a adição, remoção e configuração das entradas nesta lista.

• Grupo Protocol Distribution (protocolDist): Coleta as quantidades relativas de octetos e pacotes para os diferentes protocolos detectados no segmento da rede.

• Grupo Address Map (addressMap): Lista endereços MAC para endereços de rede descobertos pelo probe e em qual interface eles estavam na última utilização.

• Grupo Network Layer Matrix (nlMatrix): Calcula a quantidade de tráfego enviado entre cada par de endereço de rede descoberto pelo probe. Embora alMatrixControlTable também tenha objetos que controlam alMatrixTable, a implementação da alMatrixTable não é necessária para a implementação total desse grupo.

• Grupo Application Layer Host (alHost): Calcula a quantidade de tráfego, por protocolo, enviado de e para cada endereço de rede descoberto pelo probe. Implementações desse grupo requerem a implementação do grupo Network Layer Host.

Os 9 Grupos da RMON2-MIB

• Grupo Application Layer Matrix (alMatrix): Calcula a quantidade de tráfego, por protocolo, enviado de cada par de endereço de rede descoberto pelo probe. Implementações desse grupo requerem que o grupo Network Layer Matrix também seja implementado.

• Grupo User History Collection (usrHistory): O grupo usrHistory combina mecanismos usados nos grupos alarm e history para prover um mecanismo de história especificado pelo usuário utilizando três tabelas adicionais: duas de controle e uma de dados. Esta função tem sido feita tradionalmente por aplicações NMS, via polling periódico. O grupo userHistory permite que essa tarefa seja descarregada em um probe RMON. Os dados são coletados da mesma maneira que qualquer tabela de dados history (por exemplo etherHistoryTable) exceto que o usuário especifica as instâncias MIB a serem coletadas. Os objetos são coletados em bucket-groups, com o intuito de que todas as instâncias MIB no mesmo bucket-group sejam coletadas da forma mais atômica possível pelo probe RMON.

• Grupo Probe Configuration (probeConfig): Este grupo permite controlar a configuração de vários parâmetros operacionais do probe. As entradas de usrHistoryObject associadas com outra usrHistoryControlTable não precisam estar ativas antes da entrada de controle estar ativada.

Conclusão• Coletar Estatística de Níveis mais Altos: estatísticas na camada de rede

e aplicação usando as tabelas traffic, host, matrix e matrix Top N permitirão aos gerentes ver quais clientes estão falando com quais servidores, ampliando a visão da rede.

• Tradução de Endereços: amarrar endereços da camada MAC com endereços da camada de rede torna mais fácil a leitura de todos endereços. A habilidade de detectar endereços IP duplicados permitirá que os gerentes de rede solucionem problemas que devastam roteadores e LANs virtuais. Tradução de endereços e suporte a plataforma de gerência SNMP melhorará o mapeamento da topologia e aumentará a eficiência da gerência.

• História Definida pelo Usuário: o padrão RMON original permite coletar dados históricos somente em um conjunto predefinido de estatísticas. RMON2 permitirá aos gerentes de rede configurar os dados históricos de qualquer contador no sistema.

• Filtragem Melhorada: RMON2 permitirá aos usuários configurar os filtros de forma mais flexível e eficiente.

• Configuração de Probes: o padrão original RMON não lida com o problema criado na configuração e controle de diferentes probes de fornecedores diversos. O novo padrão RMON2 permitirá a configuração de diferentes marcas de probes baseados em diferentes aplicações RMON.

Documents

RMON. Introdução Criado pelos mesmos grupos que desenvolveram o TCP/IP e o SNMP, o RMON é um padrão IETF de gerenciamento de redes cuja sigla representa