IMPLANTAÇÃO E ANÁLISE DE AGENTE MONITOR DE REDES RMON2
Paulo Fernando Galvão de Oliveira Machado - IC
Cecília de Azevedo Castro Cesar - PQ
O protocolo de gerência de redes RMON2 consegue fornecer dados para a análise da camada de
aplicação. Com o seu uso, é possível detectar um padrão de utilização das aplicações de uma subrede e sugerir melhorias no protocolo de aplicação mais utilizado, neste caso, o netbios-ssn.
The RMON2 protocol can provide data to analyze the application layer. It makes possible to detect
the applications profile on a sub-network and to suggest improvements in the most used application
protocol, in this case, the netbios-ssn.
1- INTRODUÇÃO
1.1- Motivação
Com o crescimento das redes de computadores, a sua administração tornou-se trabalhosa e árdua,
além da necessidade de estudar questões além da conectividade. Com isso, surgiu a necessidade de
criação de ferramentas mais poderosas, capazes de analisar todos os níveis da camada OSI.
Em 1997, surgiu o protocolo padrão RMON2(Remote Monitoring Network 2), o qual é capaz de
analisar as camadas de 3 a 7, sendo o primeiro protocolo padrão a oferecer essa possibilidade.
1.2– Objetivo
O objetivo deste trabalho é, em princípio, implantar um agente com o protocolo RMON2 em uma
sub-rede e detectar o padrão de utilização das aplicações nesta sub-rede. A seguir, se pretende
escolher o protocolo mais utilizado e possivelmente sugerir melhorias na sua configuração.
2- O PROTOCOLO RMON2
2.1 – Características de uma MIB
Para o SNMP(Simple Network Management Protocol), a MIB(Management Information Base) é, na
sua essência, uma estrutura de dados na forma de uma árvore. Cada sistema em uma rede mantém
uma MIB a qual reflete o status dos recursos administrados por esse sistema. Uma entidade de
administração de redes pode monitorar os recursos de cada sistema através da leitura dos valores
desses objetos na MIB e pode controlar os recursos ao modificar esses valores.
2.2- Características de um agente RMON
O protocolo RMON é basicamente a definição de uma MIB. Na prática, têm-se a criação de um
padrão de funções de monitoração de redes e interfaces para a comunicação entre centrais de
gerenciamento SNMP e monitores remotos. Teoricamente, um agente RMON deve ter as seguintes
capacidades:
• Operação off-line: pode ser desejável ou necessário limitar o contato(polling) entre o
monitor e o gerente de redes.
• Monitoração proativa: se o monitor tiver recursos suficientes, ele pode continuamente fazer
diagnósticos e checar a performance da rede.
•
•
•
Detecção de problemas: a comunicação entre o agente e o console de gerenciamento
consome recursos da rede para examinar erros e condições excepcionais.
Análise de dados: o monitor da rede pode analisar os dados coletados na sua sub-rede, ao
invés delegar essa responsabilidade ao software de gerenciamento.
Múltiplos gerentes: o monitor pode ser configurado para lidar com mais de um console de
gerência simultaneamente.
A tabela 1 abaixo ilustra o escopo de atuação do protocolo RMON1 e de seu sucessor o RMON2.
Camada do modelo OSI Agente monitor padrão
Aplicação
Apresentação
RMON2
Sessão
Transporte
Rede
Enlace de dadps
RMON1
Física
Tabela 1 – Área de abrangência de cada RMON.
2.3 – A MIB RMON2
A MIB RMON2 é simplesmente uma extensão da MIB original, adicionando alguns novos
grupos. A figura 2 abaixo ilustra esse fato: no lado esquerdo temos listado os grupos originais do
RMON, enquanto no lado direito aparecem os novos grupos adicionados pela MIB RMON2.
Figura 1 – MIB RMON[3]
Como observa-se na Figura 1, os grupos organizando os dados oferecidos pelo RMON2 são:
• ProtocolDir: contém os protocolos que o agente em questão suporta.
• ProtocolDist: analisa a distribuição dos dados em relação aos protocolos.
•
•
•
•
•
AddressMap: estabele uma correlação entre os endereços da camada de enlace de dados
com os endereço da camada de rede(normalmente MAC e IP).
Host: coleta as informações baseadas em cada endereço de rede(nlHost) ou endereço de
aplicação(alHost).
Matrix: coleta as informações baseadas em pares de endereço de rede(nlMatrix) ou pares
de endereço de aplicação(AlMatrix)
UsrHistory: possibilita que as informações anteriores sejam coletadas no decorrer do
tempo.
ProbeConfig: possibilita alterar as configurações do agente em questão.
3 – MONITORAÇÃO DA REDE
3.1 – Método da coleta de dados
O ambiente utilizado para a implantação do agente foi a rede do alojamento dos alunos do ITA,
denominada Redecasd. A Figura 2 abaixo ilustra de maneira esquemática a Redecasd e a
localização relativa do agente RMON2, em um computador plugado ao hub.
Figura 2 – Redecasd com o agente instalado
Com essa forma de monitoração, esse ramo de rede pode servir como modelo de toda rede,
sempre tomando o cuidado de fazer a monitoração em grandes tempos e também sempre trabalhar
com dados normalizados.
Optou-se por trabalhar com o parâmetro número de pacotes para evidenciar a distribuição por
protocolo, visando análise das aplicações. Assim, para melhor definir o padrão das aplicações na
Redecasd, foi utilizado o parâmetro número de pacotes ao invés do número de bytes ao longo de
todo esse trabalho.
3.2 – Distribuição de aplicações no ramo dos alunos
Primeiramente foi feita a análise da rede em tempos de baixo uso. Dessa forma, pode-se
determinar qual protocolo de aplicação tem um custo inicial relativamente mais alto, o que pode
indicar um problema de configuração. A Figura 3 ilustra o resultado dessa coleta.
Figura 3 – Distribuição dos protocolos de aplicação no período de baixo uso
Fica evidente o predomínio do protocolo netbios-ssn, um protocolo usado para compartilhamento
de pastas em redes Windows. Ademais, pode-se concluir que o protocolo netbios-ssn gera mais
pacotes que os outros protocolos quando no seu estado mínimo de uso.
A fim de estabelecer se o problema com o netbios é local ou se é típico, resolveu-se fazer a
mesma coleta de dados em uma rede sem compartilhamento de pastas: uma sub-rede da Divisão
de Ciência de Computação do ITA.
Assim, foram coletados os dados referentes a quantidade de pacotes de cada protocolo, sendo o
resultado apresentado abaixo.
Figura 4 – Distribuição dos protocolos de aplicação na rede dos professores
Apesar de não ser largamente usado, o protocolo netbios aparece como o segundo mais usado.
Portanto esse protocolo, configurado da forma que se encontra na Redecasd e na rede do
Departamento de Ciência de Computação, necessita de melhorias, sendo algumas exemplificadas
na sessão a seguir.
4- ESTRATÉGIAS DE MELHORIA
4.1 – Melhorias na política de uso do protocolo
O protocolo netbios serve basicamente para permitir que aplicações locais consigam acessar
objetos remotamente, sem se preocupar com a comunicação. Dessa forma, é comum os usuários
utilizarem essa facilidade para ouvir músicas ou assistir filmes remotamente, ao invés de copiar o
filme e assisti-lo localmente.
No primeiro procedimento, as informações são fornecidas à aplicação à medida que ela a solicita,
fazendo com que o tempo de duração da sessão netbios seja dependente do tempo de duração da
aplicação. Entretanto, geralmente as aplicações tendem a ser mais demoradas que a simples cópia
do arquivo, ocupando banda por mais tempo.
Assim, uma boa prática de uso seria sempre copiar o arquivo ao invés de simplesmente acessá-lo
remotamente.
4.2 – Melhorias na Configuração do Protocolo
Cada computador em uma rede netbios é unicamente identificado por um nome. Assim, a fim de
se estabelecer uma sessão entre dois computadores é necessário obter o IP equivalente em algum
servidor, denominado de servidor de Master Browser.
Normalmente, em cada computador com Windows é possível nas suas configurações de netbios
escolher entre três opções de serviço Master Browser:
• Ativado: o computador de fato será o Master Browser;
• Automático: o computador assumirá o papel de Master Browser caso ninguém o faça;
• Desativado: o computador não será o Master Browser.
Caso dois computadores estejam configurados como Master Browser, ocorrerá um processo
denominado eleição forçada. Tal processo consiste na troca de informações entre os
computadores candidatos, com o intuito de estabelecer qual deles tem condições melhores de
oferecer este serviço.
Como todos os computadores da Redecasd estão configurados na opção de automático ocorre
que, cada vez que um computador é reiniciado, o processo de eleição forçada sucede. Tal
configuração também é encontrada nos computadores da Divisão de Ciência da Computação,
reforçando a tese de que esta configuração causa problemas para a rede.
Portanto, uma melhoria seria configurar a maioria dos computadores da rede para a opção
desativado, em relação ao Master Browser, enquanto poucos computadores estratégicos de fato
forneceriam esse serviço. Dessa forma, diminuir-se-ia consideravelmente o número de eleições
forçadas sem comprometer a velocidade da resolução de nomes netbios.
Para validar tal melhoria, fez-se um teste da sua efetividade em um período de baixo uso, sendo
que em metade dos computadores do segmento de rede alterou-se a configuração de serviço de
Master Browser para desativado. Na figura 5 segue o resultado de tal coleta de dados.
Pode-se observar uma grande queda no uso do protocolo netbios-ssn, em torno de 11%. Tal fato
caracteriza uma diminuição nos pacotes dos protocolos básicos. Com isso, conclui-se que tal
configuração de fato melhora a qualidade dos serviços utilizados na Redecasd.
Figura 5 – Distribuição dos protocolos de aplicação no período de baixo uso com melhoria
implementada
5- Conclusão
5.1- Conclusão Final
O protocolo padrão de gerência de redes RMON2 mostrou-se útil para detectar o padrão de uso
das aplicações nas redes locais. Além disso, na Redecasd em particular, com o agente RMON2,
foi possível caracterizar um quadro problemático do protocolo Netbios-ssn. Com base nisso,
embora não se tenha explorado todo o seu potencial, pode-se concluir que o RMON é
extremamente útil como ferramenta de administração de redes.
Um aspecto da gerência que deve ser destacado é o papel do administrador humano, pois, para se
atingir a melhoria, foi necessário interpretar os dados colhidos pelo agente. Assim, tão importante
quanto utilizar um bom agente monitor, é ter uma pessoa com grandes conhecidos sobre a rede
analisada, a fim de se ter uma ótima interpretação dos dados.
5.2- Trabalhos Futuros
Pode-se apontar como possibilidade de continuidade do presente trabalho:
• Obter a relação ideal entre o número de estações na rede e de servidores Master Browser;
• Investigar novas melhorias na configuração do Netbios, que ainda apresenta alto índice de
utilização;
• Investigar melhorias possíveis em outros protocolos de aplicação;
• Análise e utilização dos demais grupos do RMON2 não explorados neste trabalho.
Referências Bibliográficas
[1] Tanenbaum, A.S.: Redes de Computadores, tradução da 3ª edição, Campus, 1997.
[2] Pacitti, T.: Do Fortran à Internet, 2ª edição atualizada, Makron Books, 2000.
[3] Stallins, W.: SNMP, SNMPv2, SNMPv3 and RMON 1 and 2, 3ª edIção, Addison-Wesley,
1999.
Agradecimentos
Gostaria de agradecer ao CNPq e ao PIBIC pelo incentivo dado aos pesquisadores iniciantes.
Também gostaria de agradecer a todos que me ajudaram e foram compreensíveis como a minha
família, os meus colegas de quarto e em especial a minha orientadora Cecília.