O objeto ifInOctets implementado na MIBII refere-se apenas ao tráfego de entrada da interface monitorada. O RMON, por colocar o NIC em modo promíscuo, consegue, no objeto etherStatsOctets, acumular a estatística de todo o tráfego do segmento de rede monitorado.

Como tratam apenas o tráfego nas interfaces do equipamento monitorado, os objetos da MIBII nunca detectariam colisões, ou seja, os objetos da MIBII não têm como registrar colisões no segmento, ao contrário dos objetos RMON.

As tabelas de controle devem ser configuradas para permitir ao monitor remoto coletar dados, os quais serão armazenados nas tabelas de dados. A configuração estabelece o tipo e forma dos dados a serem coletados. Os agentes RMON são organizados em grupos de função; cada grupo pode ter uma ou mais tabelas de controle e de dados. Na tabela de Controle estão contidos os parâmetros que descrevem os dados na tabela de Dados, que é somente para leitura. Assim, as estações gerentes determinam os parâmetros apropriados. Os parâmetros são definidos pela inclusão de um novo registro na tabela, ou pela alteração de um registro existente. As funções que deverão ser executadas pelo monitor são definidas e implementadas na tabela. Alterações são feitas mediante a deleção da entrada, o que consequentemente exclui todos os registros relacionados à tabela de dados. O gerente pode, então, definir novo controle com os registros modificados.

Cada tabela de controle implementa um objeto do tipo OwnerString. Este objeto armazena o "dono" desta tabela, o qual tem permissão para adicionar ou deletar entradas e definir o compartilhamento. A utilização do objeto OwnerString permite que um gerente ou grupo de gerentes tenham acesso aos objetos da tabela de dados correspondente àquela tabela de controle, sendo que aqueles gerentes diferentes de owner podem acessar os objetos read only da tabela de dados. Como podem haver diversos conjuntos de objetos vinculados a diversos owners, há a possibilidade de formar vários grupos de gerenciamento, com visões e informações distintas. Define-se que, quando os ownerstrings começam com "monitor", os objetos da tabela de dados seriam de interesse geral para toda a comunidade de gerenciamento.

Através do objeto eventCommunity se especifica a comunidade de estações gerentes para receber os eventos enviados por agentes RMON. RMON2 implementa os objetos da tabela trapDestEntry que permitem tal configuração, especialmente os objetos trapDestCommunity e trapDestAddress

Para produzir um gráfico como o acima, podemos configurar um probe RMON2 para capturar as estatísticas de sobre o total de tráfego agrupado por portas TCP/UDP. Inicialmente, devemos configurar o grupo protocolDir para indicar os protocolos que o probe utilizará para as estatísticas. Como protocolos, devemos configurar uma entrada na tabela deste grupo para cada porta ou conjunto de portas que se deseja monitorar. Segundo o exemplo acima, foram definidos protocolos para alguns dos principais serviços da camada de aplicações (http, DNS, etc) e para capturar o tráfego UDP e TCP em geral. Após definidos os protocolos em protocolDir, as estatísticas básicas de cada um seriam armazenadas no grupo protocolDist (protocol distribution). No caso, seriam inquiridos os objetos protocolDistStatsPkts e protocolDistStatsOctets para, respectivamente, capturar estatísticas para geração do gráfico em quantidade de pacotes ou em octetos. Obviamente, as requisições a tais objetos deveriam ser feitas em intervalo(s) de tempo especificados, e os resultados de cada amostragem subtraídos da coleta anterior, objetivando calcular a variação de tráfego.

7. Pesquisa na Internet um produto que utilize RMON e outro que utilize RMON2 descrevendo-os sucintamente.

<Início>