ISSN 1518-5974
Jadson Igor Siqueira <jadson@pop-pr.rnp.br>
Elias Procópio Duarte Jr. <elias@inf.ufpr.br>
Departamento de Informática
Universidade Federal do Paraná
Resumo
1. Introdução
2. Arquitetura de Gerência Distribuída
3. O algoritmo NBND
3.1 Fase de testes
3.2 Disseminação de Informações
3.3 Diagnóstico
4. Implementação da MIB SNMP
4.1 MIB Diagnosis
4.2 Acesso à Diagnosis MIB
5. Impacto no desempenho da rede
6. Conclusões e perspectivas
Referências
Resumo
Apesar do rápido aumento de capacidade das redes de computadores, alguns problemas básicos de gerência dessas redes ainda não estão solucionados. Nesse trabalho propomos uma ferramenta para diagnóstico de links de redes. A ferramenta é baseada no algoritmo NBND. A ferramenta é implementada por agentes SNMP. Os agentes mantém uma MIB com o estado dos links da rede. Através de testes periódicos, novos eventos são detectados e posteriormente propagados para os demais nodos. Através de diretivas SNMP, os clientes podem acessar a MIB e com base nos estados dos links podem calcular quais nodos estão acessíveis e quais estão inacessíveis.
Palavras-chave
Diagnóstico Distribuído de Redes de Computadores; Agentes Distribuídos; SNMP.
1. Introdução
As organizações estão cada vez mais dependentes das redes de computadores. Novas tecnologias de redes de computadores têm proporcionado conexões de melhor qualidade, com maior capacidade e maior velocidade de transmissão. No entanto problemas básicos de gerência desses ambientes ainda não estão solucionados. Tais problemas, como o diagnóstico da queda de links, representam grande parte dos custos de manutenção dessas estruturas pois dependem de softwares de gerência de alto custo e que nem sempre são muito confiáveis. O uso desses softwares proprietários de gerência, limita a difusão das tecnologias de rede, e a sua baixa qualidade limita a confiança que podemos depositar nos ambientes distribuídos.
Nesse trabalho, apresentamos uma ferramenta de diagnóstico distribuído para redes de computadores. São abordados alguns aspectos dessa ferramenta aplicados sobre o protocolo ATM.
A ferramenta é executada em cada nodo, a unidade de processamento do sistema. A ferramenta é baseada no algoritmo de diagnóstico NBND Non Broadcast Network Diagnosis ,[1] e [3]. O NBND é um algoritmo totalmente distribuído que executa de tempos em tempos (rounds), testes nos links da rede. Quando através dos testes um evento é identificado, esse novo evento é comunicado a todos os nodos sem falha da rede. Podemos ter dois tipos de eventos, uma falha, quando um nodo que estava respondendo deixa de responder, ou uma recuperação, um nodo que não estava respondendo volta a responder.
O processo de disseminação dos novos eventos faz com que ao longo da execução do algoritmo, cada agente do sistema mantenha o estado de todos os links da rede. Definimos os estados dos links como sem-falha e timing-out. Dessa forma a qualquer momento, um cliente do sistema pode consultar as bases SNMP e a partir dos estados dos links calcular quais dentre os demais nodos estão atingíveis ou inatingívies.
A fim de obter portabilidade, a ferramenta utiliza o protocolo de gerência de redes SNMP, Simple Network Managemet Protocol,[4]. Esse protocolo apresenta grande suporte por parte dos sistemas operacionais e dos fabricantes de equipamentos de interligação de redes. Sendo suportado inclusive pelos switchs ATM do novo backbone RNP2.
Para a implementação da ferramenta escolheu-se a linguagem Tcl, [5], por sua rapidez de desenvolvimento e disponibilidade em diversos ambientes UNIX. Para implementação dos agentes SNMP escolheu-se o pacote para Tcl, Scotty [6] que oferece relativa facilidade de implementação quando comparado com outros pacotes SNMP como o UCD-Snmp.
A MIB (Management Information Base), [4], é a base de dados do SNMP que guarda o estado da rede. Essa MIB é mantida atualizada pelos agentes SNMP que rodam o algoritmo. A MIB é então consultada por clientes através de diretivas SNMP. A popularidade do SNMP garante uma ampla variedade de possíveis implementações de clientes. Optou-se pela implementação em linguagem JAVA, [8], devido à facilidade de acesso a partir de um browser instalado em qualquer plataforma.
2. Arquitetura de Gerência Distribuída
Os primeiros modelos de diagnóstico de rede que surgiram são do tipo centralizado. Nesses modelos um nodo gerente é responsável por testar todas as ligações e determinar a conectividade da rede. Esse é o modelo adotado pela maioria das ferramentas de gerência comercialmente disponíveis, como o NetView da Tivoli ,[9]. No modelo distribuído o conceito é um pouco diferente. Ao invés do sistema de gerência ser executado apenas em um único nodo, ele é executado em vários nodos do sistema. Podendo inclusive ser executado em todos eles. O sistema é organizado de forma que cada componente da ferramenta testa os links conectados ao nodo em que está sendo executado. Então esses nodos trocam informações para que todos tenham uma posição global do sistema.
Ambos os modelos têm suas peculiaridades. O modelo centralizado, a uma primeira vista parece ser mais facilmente implementado. Porém sua disponibilidade fica comprometida pois se ocorre uma falha no nodo gerente toda a rede fica sem um monitor. Enquanto que no modelo distribuído, mesmo na presença de falha em alguns dos nodos, os nodos sem falha continuam monitorando a rede.
Mais ainda, imaginemos que ocorra uma falha na rede. E que essa falha divida a rede em duas partes. Ou seja, temos 2 componentes desconexos. Nesse caso, com o sistema centralizado, a parte da rede que não mantém comunicação com o nodo gerente fica sem informação mesmo dos nodos do seu componente. Enquanto que no modelo distribuído dentro de cada componente, cada nodo sem falha continua mantendo informação a respeito dos outros nodos. O que sem dúvida é uma vantagem considerável.
Figura 1 - Arquitetura da ferramenta
Seguindo o modelo de agentes do SNMP, propomos uma arquitetura baseada em agentes distribuídos pelos nodos da rede. É possível que a ferramenta esteja presente em cada nodo. Ou ainda, é possível que tenhamos um agente em cada sub-rede do sistema, conforme ilustrado na figura 1.
Os agentes rodando o algoritmo NBND, comunicam-se entre si de forma a trocar informações a respeito da rede. Os clientes, a qualquer momento podem consultar os agentes a fim de obter o estado atual da rede.
3. O algoritmo NBND
Nessa seção explica-se o funcionamento da ferramenta de acordo com as três fases previstas no algoritmo NBND (Non Broadcast Network Diagnosis).
3.1 Fase de testes
Os testes são executados periodicamente de acordo com o round. O round é o tempo decorrido entre uma bateria de testes e outra. Em uma rede de computadores, um valor usualmente assinalado para o round seria 30 segundos.
A ferramenta está projetada de forma que a tecnologia de implementação do teste seja independente do algoritmo. Neste trabalho apresentamos algumas possíveis estratégias, no entanto outras também poderiam ser elaboradas. Diferentes estratégias de teste podem ser utilizadas em diferentes partes da rede.
Figura 2 - Estratégias de testes
É possível a implementação da estratégia de testes utilizando um esquema de comunicação sem confirmação automática, no estilo "send, receive" como o ICMP ou UDP. Para esse tipo de comunicaçao são apresentadas em [2] duas abordagens diferentes. O texto contém uma descrição detalhada de cada uma delas e uma comparação entre as duas. Elas são chamadas de "Two-way test" e "Token test". Basicamente, elas funcionam da seguinte maneira:
- O Two-way test monitora os links por meio de um teste onde o nodo testador manda uma mensagem para o outro nodo e esse responde imediatamente.
- Já no Token test o nodo testador manda uma mensagem para o nodo testado, mas a resposta não é imediata, o nodo testador está mandando o token, e recebe-o de volta ao final de um intervalo de teste.
No referido artigo há ainda uma comparação entre as duas estratégias. O Token test mostra-se que na média, o Token Test é aproximadamente 50% mais rápido na detecção de eventos que o Two-way Test. A figura 2 mostra a seqüência de execução das duas abordagens para um round de 30 segundos.
Um problema enfrentado por esse tipo de abordagem são os alarmes falsos. Devido ao congestionamento dos links, algumas vezes mensagens de teste são perdidas e o link é erroneamente diagnosticado como falho. Em redes ATM, seria possível a reserva de um PVC para a ferramenta de gerência. Esse PVC teria uma pequena banda garantida, para que os pacotes de teste não fossem descartados.
3.2 Disseminação de Informações
Como a ferramenta é distribuída, é necessário uma forma de comunicação que permita que todos os nodos tenham informações atualizadas a respeito dos outros nodos. Tal comunicação ocorre na fase de disseminação. Quando um novo evento é descoberto, a informação sobre o novo estado do link deve ser disseminada para todos os nodos alcançáveis. A ferramenta de diagnóstico emprega uma estratégia baseada numa árvore de busca em largura que emprega o menor número possível de mensagens. As mensagens são pequenas, necessitando de apenas três campos, dois endereços IP e um contador de estados de 32 bits. Conforme ilustrado na figura 3.
Figura 3 - Estrutura da mensagem de disseminaçãO
A árvore de disseminação é montada com base na estrutura de interligação da rede que os nodos mantém na MIB, a tabela de links. Essa tabela de links é lida da MIB e transformada numa lista de adjacências a partir da qual a árvore de disseminação é montada. Uma vez de posse dessa árvore de disseminação os nodos que detectam o evento disseminam a nova informação para os nodos que figuram como seus filhos de acordo com a árvore. Cada nodo da árvore ao receber a informação também a dissemina para seus filhos. Dessa forma todos os nodos são informados do novo evento. A figura 4 ilustra as árvores formadas pelos nodos A e B quando do descobrimento de um evento no link A-B.
Figura 4 - Construção da árvore de disseminação
A disseminação seguindo a estrutura da árvore só é possível se todos os nodos montarem a mesma árvore. Essa condição é garantida pela preservação de duas propriedades:
- A tabela tem de ser lida de forma ordenada.
- Todos os nodos tem de ter armazenadas as mesmas informações;
A primeira condição é facilmente preservada pelo armazenamento das informações na tabela de maneira indexada. De fato a MIB implementada é indexada pelo (par nodo1, nodo2) de cada link.
Para garantir a segunda condição, é necessário que uma disseminação termine antes do intervalo de testes seguinte. O que é bem plausível se considerarmos que o tempo de disseminação das mensagens é da ordem de milisegundos enquanto que o round, i.e o intervalo de testes, é de dezenas de segundos.
3.3 Diagnóstico
A ferramenta permite que clientes autorizados verifiquem o estado de conectividade da rede a partir de um browser Web. Podem ser consultados estados de links específicos. Ou pode-se consultar todos os links da rede e a partir desses calcular a conectividade do sistema.
O programa cliente pode manter um desenho da topologia. Com as informações coletadas da MIB pode mostrar de maneira diferenciada os links sem-falha e os timing-out, os nodos atingíveis e os inatingíveis.
4. Implementação da MIB SNMP
A ferramenta é implementada como um agente SNMP que roda o algoritmo de diagnóstico. O objetivo do algoritmo é manter uma tabela com o estado de todos os links. A partir dessa tabela podem ser extraídas informações de conectividade.
4.1 MIB Diagnosis
Nesta seção é proposta uma MIB SNMP desenvolvida para representar a topologia da rede. É utilizada uma tabela de links da rede, com uma entrada para um contador de estados por link. Abaixo segue a especificação ASN.1, usada pelo SNMP. O desenho da figura 5 ilustra a árvore da MIB SNMP
==============================================
==============================================
Diagnosis-MIB DEFINITIONS ::= BEGIN
- -- Diagnosis MIB.
- --
- -- Autores: Elias P. Duarte Jr.
Jadson I. Siqueira
- --
- -- e-mail: elias@inf.ufpr.br
jadson@pop-pr.rnp.br
- --
- -- Universidade Federal do Paraná
- -- Departamento de Informática, Curitiba, Brasil
- --
- -- 2000
- --
IMPORTS
mib-2, IpAddress, Counter32, enterprises, OBJECT-TYPE
FROM SNMPv2-SMI
DisplayString
FROM SNMPv2-TC;
ufpr OBJECT IDENTIFIER ::= { enterprises 2022 }
nbnd OBJECT IDENTIFIER ::= { ufpr 5 }
diagTableDescr OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
" Descrição da mib de diagnóstico distribuído."
::= { nbnd 1 }
diagTable OBJECT-TYPE
SYNTAX SEQUENCE OF DiagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Uma tabela contendo todos os links da rede."
::= { nbnd 2 }
DiagEntry OBJECT-TYPE
SYNTAX diagEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Cada entrada corresponde a um link da rede.
O link é indexado pelo endereço IP do par
de nodos que o conecta (nodo1, nodo2)."
INDEX { nodo1, nodo2 }
::= { diagTable 1 }
diagEntry ::=
SEQUENCE {
node1
IpAddress,
node2
IpAddress,
eventCounter
counter32
}
node1 OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"O primeiro nodo no qual o link incide.
OBS: A tabela não guarda links repetidos,
por exemplo, o link (1,2) é igual ao link (2,1)"
::= { diagEntry 1 }
node2 OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"O segundo nodo no qual o link incide."
::= { diagEntry 2 }
eventCounter OBJECT-TYPE
SYNTAX Counter32
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Um contador de estados do link.
Valores pares indicam que o nodo está "sem-falha",
valores ímpares indicam nodo "timing-out" "
::= { diagEntry 3 }
==============================================
==============================================
4.2 Acesso à Diagnosis MIB
O SNMP provê diretivas de acesso para leitura e para escrita às variáveis das diversas MIBs disponíveis. Os acesso são regidos pelo controle de acesso do SNMP, [4]. Esse controle de acesso é feito com base no endereço IP de origem, numa string de password chamada community e na árvore de MIBs, que pode ser dividida em visões. Nas configurações de acesso dos agentes SNMP devem ser tomados algumas precauções com relação a segurança. A liberação indiscriminada do acesso de escrita pode ser perigosa. Algumas MIBs quando maliciosamente alteradas podem comprometer o bom funcionamento do sistema.
É adequado que apenas os agentes tenham acesso de leitura e escrita. E os clientes tenham acesso restrito à leitura. Através das visões, pode-se limitar o acesso tanto dos agentes quanto dos clientes somente para as variáveis da MIB Diagnosis. E ainda é possível restringir esse acesso a endereços IP previamente estabelecidos.
Figura 5 - Estrutura da MIB Diagnosis
Os acessos são feitos pelas diretivas GET e SET do SNMP. Abaixo seguem alguns exemplos de acessos e seus significados:
SET diagTable.diagEntry.eventCounter.10.0.0.1 . 10.0.0.2 = 0 . =
Inicializa o link entre os nodos 10.0.0.1 e 10.0.0.2 com o valor 0. Valores pares representam link sem-falha, valores ímpares representam link timing-out
SET diagTable.diagEntry.eventCounter.10.0.0.1.10.0.0.2 = 1
Nesse caso um agente descobre que o link entre 10.0.0.1 e 10.0.0.2 ficou falho e o incrementa para 1, indicando link timing-out.
GET diagTable.diagEntry.eventCounter.10.0.0.1 . 10.0.0.2 . Retorno = 3.
Consulta o eventCounter do link entre os nodos 10.0.0.1 e 10.0.0.2. O resultado da consulta retornado indica que o link está timing-out.
GET diagTable.diagEntry.node1.10.0.0.1.10.0.0.2 = 3
Consulta o eventCounter do link entre os nodos 10.0.0.1 e 10.0.0.2. O resultado da consulta retornado é 3. O valor impar 3, indica que o link está timing-out.
Os Agentes executam testes periódicos nos nodos vizinhos e a medida que detectam novos eventos atualizam as sua MIB e disseminam a informação para os outros agentes. Os clientes podem ler as MIBs dos agentes para obter informações a respeito do estado da rede.
Os clientes podem consultar na MIB, o estado de algum link em específico. Podem também consultar a tabela inteira ou uma porção dela e a partir da tabela executar um algoritmo de conectividade.
5. Impacto no desempenho da rede
Um aspecto que poderia ser questionado é a carga adicional gerada pela ferramenta. O processo de diagnóstico e a disseminação de eventos regularmente geram mensagens adicionais na rede. No entanto estima-se que essas mensagens não sejam relevantes dado o pequeno tamanho das mensagens e a esporadicidade de suas ocorrências.
Em [1] algumas medições foram feitas para um algoritmo semelhante ao aqui apresentado. Foram consideradas taxas de erro de 0.001, tamanho das mensagens de 128bytes. E de fato, para links de 28.8Kbps a 2Mbps as medições indicaram uma sobrecarga inferior a 0.1% da capacidade dos links. Considerando a atual capacidade dos links essa carga torna-se ainda mais despresível.
6. Conclusões e perspectivas
Nesse trabalho é proposta uma ferramenta para diagnóstico distribuído de falhas em redes de computadores. A ferramenta é baseada no algoritmo para diagnóstico de redes de topologia arbitrária NBND. A arquitetura da ferramenta é baseada em um modelo de agentes distribuídos. Uma MIB é proposta para a implementação dos agentes SNMP .
Os clientes acessam a MIB via diretivas SNMP. Essa arquitetura dá grande flexibilidade ao sistema, tornando independente dos clientes, a camada que executa os testes e mantém a MIB. Com um cliente implementado em Java, por exemplo, é possível que um usuário autorizado consulte o estado da rede a partir de um browser sobre qualquer plataforma.
A fase de testes também é independente das outras partes da ferramenta, sendo possível algumas variações na estratégia de testes utilizada. Numa rede ATM, é sugerida a reserva de um PVC para a troca de mensagens de diagnóstico, afim de que os usuais alarmes falsos decorrentes de links congestionados sejam evitados.
Como perspectivas de trabalhos futuros, é possível incorporar à mesma arquitetura proposta, outras funcionalidades além do diagnóstico dos links. A ferramenta poderia ser estendida para atuar com outras MIBs. Poderia controlar parâmetros ATM como VCIs e VPIs, poderia monitorar ocupação de interfaces, etc. A forma de coleta desses dados, assim como é a fase de testes na arquitetura atual, seria independente do restante da ferramenta. No entanto poderia ser utilizada a mesma estratégia de disseminação de informações entre os agentes. E o mesmo tipo de acesso pelos clientes.
Referências
[1] DUARTE JUNIOR, E. P.; MANSFIELD, G.; NANYA T. e NOGUCHI, S.. Non-Broadcast Network Fault Mionitoring Based on System-Level Diagnosis, Proc. IEEE/IFIP IM'97, pp. 597-609, San Diego, May 1997.
[2] SIQUEIRA, J. I.; DUARTE JUNIOR, E. P.. A Token-Based Testing Strategy for Non-Broadcast Network Diagnosis, 1st Latin American Test Workshop, pp. 235, Rio de Janeiro, March 2000.
[3] FABRIS, E.; SIQUEIRA, J. I.; DUARTE JUNIOR, E. P.. Simulação de um Algoritmo de Diagnóstico em Redes Ponto a Ponto, 25o Congresso da Sociedade Brasileira de Computação, Anais do CTIC, pag 236, Rio de Janeiro, Julho de 1999.
[4] ROSE, M. T.. The Simple Book - An Introduction to Internet Management, 2nd ed., PrenticeHall, Englewood Cliffs, NJ, 1994.
[5] WELCH, B. B.. Practical Programming in Tcl & Tk, PrenticeHall, 1997.
[6] ZELTZERMAN, D., PUOPLO, G.. Building Network Management Tools with Tcl/TK, PrenticeHall, 1998.
[7] SEDGEWICK, R.. Algorithms in C,Addison-Wesley, Reading, MA, 1992.
[8] LEMAY, L.;LEMBO, A.,PERKINS, C. L.. Java Aprenda em 21 dias, Editora Campus, 1996.
[9] TIVOLI SYSTEMS INC.. Tivoli NetView. http://www.tivoli.com/products/index/netview
NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004