Área de redes de computadores por axel krieger …siaibib01.univali.br/pdf/axel krieger...

98
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE REDES Área de Redes de Computadores por Axel Krieger Neto Fabrício Bortoluzzi, M.Sc. Orientador Itajaí (SC), fevereiro de 2009

Upload: others

Post on 21-May-2020

5 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE REDES

Área de Redes de Computadores

por

Axel Krieger Neto

Fabrício Bortoluzzi, M.Sc. Orientador

Itajaí (SC), fevereiro de 2009

Page 2: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR

CURSO DE CIÊNCIA DA COMPUTAÇÃO

UNMS: PLATAFORMA UNIFICADA PARA O GERENCIAMENTO DE REDES

Área de Redes de Computadores

por

Axel Krieger Neto Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Fabrício Bortoluzzi, M.Sc.

Itajaí (SC), fevereiro de 2009

Page 3: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

ii

AGRADECIMENTOS

Agradeço a:

• Meu pai por seu apoio e compreensão, essenciais para a conclusão deste curso.

• Minha mãe pelo grande incentivo dado durante toda a vida estudantil.

• Orientador Fabrício Bortoluzzi que foi bastante requisitado por sugestões e criticas

durante todo o projeto.

• Ademir Goulart professor que me demonstrou pela primeira vez, o funcionamento de

softwares de gerência de redes e que despertou a curiosidade sobre o assunto.

• Francis Benito Odisi por autorizar a utilização de componentes de desenvolvimento

gráfico e de acesso a banco de dados, ambos de sua autoria.

• Todos os colegas do curso de Ciência da Computação sem os quais muitos

conhecimentos deixariam de ser aprendidos.

Page 4: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

iii

SUMÁRIO

LISTA DE ABREVIATURAS...................................................................v

LISTA DE FIGURAS................................................................................vi LISTA DE TABELAS.............................................................................viii RESUMO....................................................................................................ix

ABSTRACT.................................................................................................x

1 INTRODUÇÃO ......................................................................................1 1.1 PROBLEMATIZAÇÃO................................................................................... 2 1.1.1 Formulação do Problema .............................................................................. 2 1.1.2 Solução Proposta ............................................................................................ 3 1.2 OBJETIVOS ..................................................................................................... 4 1.2.1 Objetivo Geral................................................................................................ 4 1.2.2 Objetivos Específicos...................................................................................... 4 1.3 METODOLOGIA............................................................................................. 4 1.4 ESTRUTURA DO TRABALHO ..................................................................... 5

2 FUNDAMENTAÇÃO TEÓRICA ........................................................6 2.1 .NET FRAMEWORK E PROJETO MONO.................................................. 6 2.1.1 .NET Framework ........................................................................................... 6 2.1.2 Projeto Mono.................................................................................................. 9 2.2 MODELOS, ARQUITETURAS E PROTOCOLOS DE GERÊNCIA........ 12 2.2.1 Conceitos....................................................................................................... 12 2.2.2 FCAPS: Fault, Configuration, Accounting, Performance and Security ... 14 2.2.3 CMIP/CMISE............................................................................................... 15 2.2.4 SNMP............................................................................................................ 17 2.3 SOFTWARES DE MONITORAMENTO..................................................... 27 2.3.1 Nagios............................................................................................................ 27 2.3.2 Cacti .............................................................................................................. 33 2.3.3 Tabela comparativa de softwares de gerência de redes ............................. 38

3 PROJETO.............................................................................................40 3.1 REQUISITOS FUNCIONAIS, NÃO FUNCIONAIS E REGRAS DE NEGÓCIO.............................................................................................................. 41 3.1.1 Motor ............................................................................................................ 42 3.1.2 Interface com o usuário ............................................................................... 43 3.2 DIAGRAMAS DE CASO DE USO ............................................................... 44 3.2.1 Motor ............................................................................................................ 44 3.2.2 Interface com o usuário ............................................................................... 45 3.3 DIAGRAMAS DE CLASSE .......................................................................... 60 3.3.1 Motor ............................................................................................................ 61

Page 5: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

iv

3.3.2 Interface........................................................................................................ 62 3.4 DIAGRAMA ENTIDADE-RELACIONAL.................................................. 63

4 Desenvolvimento...................................................................................64 4.1 CLASSE DE MANIPULAÇÃO DE DADOS DO PROTOCOLO SNMP... 65 4.1.1 Padrão TLV.................................................................................................. 66 4.1.2 Codificação/Decodificação BER.................................................................. 67 4.1.3 A biblioteca de classes resultante ................................................................ 68 4.2 O MOTOR DO UNMS................................................................................... 70 4.2.1 Checando através de ICMP......................................................................... 71 4.2.2 Checando serviços ........................................................................................ 72 4.2.3 Checando os OIDs........................................................................................ 72 4.3 DESENVOLVIMENTO DA INTERFACE .................................................. 73 4.3.1 Construção de gráficos na plataforma .NET.............................................. 74 4.3.2 Exibindo hosts no Google Earth.................................................................. 76 4.3.3 Desenvolvimento da auto-descoberta de dispositivos................................. 78 4.4 TESTES DO UNMS ....................................................................................... 79 4.4.1 Processo de testes da biblioteca de acesso SNMP....................................... 79 4.4.2 Testes da ferramenta.................................................................................... 80

5 CONCLUSÕES ....................................................................................83

REFERÊNCIAS BIBLIOGRÁFICAS ...................................................85

Page 6: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

v

LISTA DE ABREVIATURAS

API Application Programming Interface ASN.1 Abstract Syntax Notation One BCL Base Class Library BER Basic Encoding Rules CLR Common Language Runtime CMIP Common Management Interface Protocol CMIS Common Management Information Service CMISE Common Management Information Service Element CMOT Common Management over TCP/IP EGP Exterior Gateway Protocol FCAPS Fault, Configuration, Accounting, Performance and Security GPL General Public License ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IL Intermediate Language ISO International Standards Organization ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization Sector JIT Just in Time Compilation LPP Lightweight Presentation Protocol MIB Management Information Base NGWS Next Generation Windows Services NMS Network Management System OID Object Identifier OSI Open Systems Interconnection PDU Protocol Data Unit RFC Release For Comments SGBD Sistema Gerenciador de Banco de Dados SMI Structure of Managed Information SNMP Simple Network Management Protocol TCC Trabalho de Conclusão de Curso TLV Type, Length and Value TMN Telecommunications Management Networks UNIVALI Universidade do Vale do Itajaí UNMS Unified Network Management System XML Extensible Markup Language

Page 7: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

vi

LISTA DE FIGURAS

Figura 1. A Arquitetura .NET. .........................................................................................................8 Figura 2. Tratamento de arquivos para sistemas multi-plataforma....................................................9 Figura 3. GTK# no Linux. .............................................................................................................10 Figura 4. GTK# no Windows.........................................................................................................10 Figura 5. Código fonte para detecção de plataforma.......................................................................11 Figura 6. Resultado da detecção do sistema operacional no Linux. ................................................11 Figura 7. Resultado da detecção do sistema operacional no Windows XP. .....................................11 Figura 8. Status do desenvolvimento do namespace System. ..........................................................12 Figura 9. MIB do ambiente de gerenciamento Internet...................................................................13 Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS.....................................................16 Figura 11. Relação entre o NMS e o Agente. .................................................................................18 Figura 12. A árvore de objetos da SMIv1.......................................................................................20 Figura 13. Primeiras linhas de uma MIB........................................................................................20 Figura 14. Formato da declaração de objetos gerenciáveis. ............................................................21 Figura 15. Definição de objetos gerenciáveis. ................................................................................21 Figura 16. Definição da Sequence IfEntry......................................................................................22 Figura 17. SMIv2 e novos ramos. ..................................................................................................22 Figura 18. Definição de objetos gerenciáveis na SMIv2.................................................................23 Figura 19. MIB-II. .........................................................................................................................25 Figura 20. Tela inicial do Nagios. ..................................................................................................30 Figura 21. Detalhes dos hosts. .......................................................................................................31 Figura 22. Detalhes dos serviços....................................................................................................32 Figura 23. Recurso “Mapa da Rede”..............................................................................................33 Figura 24. Tela inicial do Cacti......................................................................................................34 Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti...........................................37 Figura 26. Visualizando gráficos no Cacti......................................................................................38 Figura 27. Exemplo de uso. ...........................................................................................................40 Figura 28. Modelo em camadas. ....................................................................................................41 Figura 29. Diagrama de casos de uso do Motor..............................................................................44 Figura 30. Diagrama de casos de uso da interface. .........................................................................45 Figura 31. Interface de login. .........................................................................................................46 Figura 32. Interface principal do cadastro de hosts.........................................................................48 Figura 33. Interface de configuração de monitoramento.................................................................49 Figura 34. Interface de cadastro de serviços. ..................................................................................51 Figura 35. Interface de cadastro de usuários...................................................................................52 Figura 36. Interface de visualização de estados de hosts. ...............................................................53 Figura 37. Interface de visualização de estados dos serviços dos hosts. ..........................................54 Figura 38. Interface de visualização da topologia da rede...............................................................55 Figura 39. Interface para a chamada da visualização de hosts no Google Earth. .............................56 Figura 40. Visualização de gráficos. ..............................................................................................57 Figura 41. Visualização de eventos. ...............................................................................................58 Figura 42. Detectando hosts...........................................................................................................60 Figura 43. Diagrama de classes do motor.......................................................................................61 Figura 44. Diagrama Entidade-Relacional......................................................................................63 Figura 45. Formato de desenvolvimento. .......................................................................................65 Figura 46. Datagrama SNMP.........................................................................................................66

Page 8: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

vii

Figura 47. Espaço community do SNMP. ......................................................................................66 Figura 48. Valor binário de sete em sete bits..................................................................................68 Figura 49. Resultado da codificação BER. .....................................................................................68 Figura 50. Métodos da classe de codificação/decodificação BER...................................................68 Figura 51. Métodos da classe de Snmp. .........................................................................................69 Figura 52. Métodos e atributos da classe SnmpData.......................................................................70 Figura 53. Métodos da classe ICMP. .............................................................................................71 Figura 54. Exemplo de uso para o .Net Charting e seu logotipo. ....................................................74 Figura 55. .Net Charting no Visual Studio. ....................................................................................74 Figura 56. .Net Charting e gráfico de barras...................................................................................75 Figura 57. Exemplo de uso do .Net Charting..................................................................................75 Figura 58. Exemplo de KML. ........................................................................................................77 Figura 59. Google Earth exibindo os hosts.....................................................................................78 Figura 60. Wireshark detectando os datagramas SNMP. ................................................................79 Figura 61. Comparando o datagrama correto (linha superior) e o incorreto (linha inferior).............80 Figura 62. O gráfico construído corretamente para medir a carga de processamento de um host. ...82

Page 9: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

viii

LISTA DE TABELAS

Tabela 1. Tipos de dados SMIv1....................................................................................................19 Tabela 2. Novos tipos de dados da SMIv2 .....................................................................................23 Tabela 3. Aprimoramentos na definição de objetos. .......................................................................23 Tabela 4. Novos termos .................................................................................................................24 Tabela 5. Explicação dos ramos da MIB-II ....................................................................................25 Tabela 6. Tipos de traps.................................................................................................................27 Tabela 7. Lista dos principais plugins do Nagios ...........................................................................28 Tabela 8. Arquivos padrões de configuração do Nagios .................................................................29 Tabela 9. Tabela comparativa de softwares de gerência de redes....................................................39 Tabela 10. Bibliotecas SNMP pesquisadas.....................................................................................66 Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV........................................67 Tabela 12. Dados sobre o segundo teste.........................................................................................81

Page 10: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

ix

RESUMO

KRIEGER NETO, Axel. UNMS: Plataforma Unificada para Gerenciamento de Redes. Itajaí, 2008. 98 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2009. Com a expansão das redes de computadores, tornou-se necessária a utilização de softwares que monitorem seus recursos. A necessidade de gerenciamento otimizado resultou em vários padrões, arquiteturas e protocolos de gerência além de softwares de monitoramento de estados e grafadores. Neste trabalho é demonstrado o processo de desenvolvimento do UNMS, um software de monitoramento de redes construído para a plataforma .NET e que une estes dois principais recursos. O estudo e compreensão do SNMP no nível de seus datagramas durante este processo bem como as regras básicas de codificação e o TLV foram documentados neste TCC. O resultado deste processo é um software de código aberto, com um motor que se torna multi-plataforma se utilizado junto com o projeto Mono. Palavras-chave: Gerência de Redes. Monitoramento de Redes. NMS. Plataforma .NET. SNMP. TLV. Regras básicas de codificação. Projeto Mono.

Page 11: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

x

ABSTRACT

Expansion of computer networks has made it necessary to use software to monitor netwoirking

resources. The need for optimal management resulted in several standards, architectures and

protocols in addition to the monitoring softwares of state diagrams and graphers. This work

demonstrates the development process of UNMS, a network monitoring software built for the .NET

plataform and that unites those two main resources. The study and understanding at datagram level

of SNMP during this process such as the basic encoding rules and TLV were documented in this

paper. The result of this process is an open-source software, with a multi-plataform engine using

Mono Project.

Keywords: Network Management. Network Monitoring. NMS. .NET Plataform. SNMP. TLV. Baisc

Encoding Rules. Mono Project.

Page 12: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

1 INTRODUÇÃO

As redes de computadores se tornaram presentes na maioria das organizações modernas.

Poucas áreas, em um período tão curto, apresentaram tantas revoluções tecnológicas quanto as

Redes de Computadores (TANENBAUM, 2003).

O uso e a dependência da Internet como instrumento de agilidade para os negócios faz com

que as Redes de Computadores sejam altamente utilizadas. O número de sistemas que necessitam

desta tecnologia vem aumentando significativamente, tornando necessária a existência de rotinas

que monitoram os diversos equipamentos que compõem a rede, como roteadores, switches, access

points, computadores, etc., garantindo que os dispositivos não estejam apenas funcionando, mas

também operando de forma otimizada. Para este propósito, foram criados protocolos de gerência de

redes como o SNMP (Simple Network Management Protocol – Protocolo Simples de Gerência de

Redes) e o CMIP (Common Management Information Protocol – Protocolo de Gerência de

Informações Comuns). O processo de monitoramento é considerado uma parte do processo de

gerenciamento de rede.

Gerenciamento de rede inclui o oferecimento, a integração e a coordenação de hardware, software e humanos, para monitorar, testar, consultar, configurar, analisar, avaliar e controlar os recursos da rede, e de elementos, para satisfazer às exigências operacionais, de desempenho e de qualidade de serviço em tempo real a um custo razoável (SAYDAM, 1996).

O protocolo SNMP é o padrão de facto para a obtenção de tais indicadores (MAURO;

SCHMIDT, 2001, tradução nossa) sendo, portanto, o protocolo adotado para a construção do

UNMS.

A tarefa de se encontrar um único software que trate todas as necessidades de gerenciamento

não é trivial e geralmente frustra o administrador, já que dificilmente se encontra algum software

que, ao mesmo tempo em que monitora os recursos, faz gráficos de carga e produz alertas. Além

disso, os softwares de gerenciamento costumam ser de difícil configuração, já que a maioria é

configurada através de arquivos de texto, que em muitos casos são muito complexos. Também

existem os softwares de difícil utilização, obrigando o administrador da rede a estudar dezenas de

linhas de comando para se extrair um mínimo de informação.

Atualmente, existem vários softwares que monitoram a rede em utilização, como por

exemplo, o Nagios (NAGIOS, 2008) e o Cacti (CACTI, 2008). Vários administradores de rede

Page 13: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

2

utilizam os dois em conjunto. O Nagios monitora os recursos da rede e emite alertas mediante

estados indesejados. Já o Cacti grafa a carga e/ou utilização de recursos. Neste cenário, ocorre a

dificuldade de configurar, já que ambos são manipulados em ambientes distintos, fazendo-se

necessário o cadastro dos equipamentos duas vezes, ou mais, se o administrador considerar

necessárias outras ferramentas de apoio à gestão da infra-estrutura, gerando redundância de dados

entre outros problemas.

Neste trabalho, é demonstrada a construção de um software chamado UNMS (Unified

Network Management System – Sistema de Gerenciamento de Redes Unificado), cujo objetivo é de

tratar a dependência de mais de um software de gerencia de redes evitando as redundâncias

descritas.

Destaca-se o estudo em mais baixo nível do protocolo SNMP. Isto foi necessário devido a

falta de bibliotecas nativas do .NET que tratam deste protocolo.

1.1 PROBLEMATIZAÇÃO

A problematização do presente trabalho será abordada através da:

• Formulação do problema; e

• Solução Proposta.

1.1.1 Formulação do Problema

Pode-se considerar que existe, atualmente, uma grande dependência da Internet como

ferramenta do dia-a-dia, resultando em um alto grau de uso de redes de computadores. Devido a

este crescimento, houve a necessidade da criação de sistemas que monitoram e gerenciam todos os

dispositivos de rede.

Os sistemas atuais que monitoram a rede foram criados para solucionar parte dos problemas.

Uns simplesmente monitoram os estados dos hosts, emitindo alertas ou apenas exibindo

informações sobre eles. Outros ainda exibem informações de serviços de rede como um servidor

Web por exemplo. Ainda existem sistemas que constroem gráficos de utilização de recursos, que

permitem ao administrador de rede, visualizar as informações de um modo mais fácil e amigável,

podendo resultar em tomadas de decisão mais eficientes e corretas.

Page 14: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

3

Devido a existência de vários tipos de sistemas de monitoramento de redes, existe também a

necessidade de possuir mais de um, com a finalidade de garantir um alto grau de controle sobre a

rede. Ao utilizar vários sistemas de monitoramento o administrador da rede é forçado a configurar

cada um individualmente, podendo resultar em inconsistências.

Além disso, existem casos em que sistema é de difícil utilização, sendo apenas executado

usando linhas de comando na maioria das vezes bastante extensas. Outros ainda são de difícil

configuração, sendo ajustados por vários arquivos de texto, obrigando o administrador a estudá-los

exaustivamente antes que consiga algum tipo de resultado.

Analisando pelo lado do desenvolvedor de softwares, existe também uma ausência de

bibliotecas de classes, que fazem com que a utilização do protocolo SNMP seja mais simples. A

existência de bibliotecas que atinjam esta necessidade fará com que o desenvolvedor se preocupa

mais com a lógica de negócio e reduzindo o tempo de construção de softwares.

1.1.2 Solução Proposta

Neste trabalho foi construída uma ferramenta de gerência de redes de computadores que é

fácil de utilizar, configurar e instalar. Além disto, o motor desta ferramenta é compatível com vários

sistemas operacionais diferentes. O envio de alertas da ferramenta é limitado à exibição destes na

tela e ao envio de emails.

A solução sanou problemas das soluções similares analisadas. As soluções de

monitoramento estudadas foram o Nagios (NAGIOS, 2008) e Cacti (CACTI, 2008).

O motor do UNMS foi construído utilizando o projeto Mono, uma implementação de código

aberto da plataforma .NET, que permite aos programadores criarem e executarem aplicações em

vários sistemas operacionais como Linux, Mac OS X e o Windows. A linguagem que foi adotada

para a construção da ferramenta é a C# e o SGBD (Sistema de Gerenciamento de Banco de Dados)

será o PostgreSQL. Já a interface foi construída ignorando aspectos de compatibilidade com o

projeto Mono.

Buscando facilitar a utilização do SNMP na plataforma .NET bem como o correto

funcionamento do motor, foi construído uma biblioteca de classes própria. Esta contém uma classe

principal que manipula as informações do protocolo através de métodos estáticos, tornando seu uso

direto e objetivo.

Page 15: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

4

1.2 OBJETIVOS

Os objetivos do trabalho são compostos pelo objetivo geral e por cinco objetivos

específicos.

1.2.1 Objetivo Geral

O objetivo geral deste trabalho é especificar e produzir um software de gerência para redes

de computadores com interface gráfica local que contemple as tarefas de mapas de estado e

grafagem de objetos, endereçando as principais dificuldades encontradas no uso dos softwares de

mesmo propósito disponíveis para uso.

1.2.2 Objetivos Específicos

Os objetivos específicos deste projeto de pesquisa são:

• Listar as principais características de softwares de gerência de redes de código aberto;

• Compreender a especificação .NET implementada através do projeto de código-fonte

aberto Mono;

• Especificar e construir o UNMS;

• Testar e validar o comportamento do UNMS aplicando-o em uma infra-estrutura de

rede; e

• Documentar o desenvolvimento e os resultados do sistema.

1.3 Metodologia

A realização da primeira parte do trabalho de conclusão de curso seguiu duas etapas

principais: estudo e projeto.

A primeira parte do trabalho teve como objeto de estudo a plataforma .NET e o projeto

Mono. Além disso, foram estudadas as arquiteturas, protocolos e conceitos relacionados à gerência

de redes, necessários para compreender como construir a solução proposta. Também, foram

estudados outros aplicativos de gerência de redes, através dos quais foi possível enumerar vários

recursos interessantes. Todos os estudos foram realizados utilizando a Internet e livros, e os

resultados foram descritos na seção de Fundamentação Teórica.

Page 16: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

5

A etapa de projeto teve como objetivo modelar o sistema através da construção de

diagramas de caso de uso, classe e entidade-relacional. Os recursos mais importantes enumerados,

ainda na etapa anterior, foram considerados na elaboração do projeto.

A etapa de desenvolvimento foi a que englobou a criação das bibliotecas básicas e a

construção do motor e da interface. Além disso, foram realizados estudos adicionais e mais

aprofundados, necessários para a construção de alguns recursos.

1.4 Estrutura do trabalho

A estrutura deste trabalho é composta por quatro seções principais: Introdução,

Fundamentação Teórica, Projeto, Desenvolvimento e Conclusão.

A Introdução aborda o trabalho como um todo, explicando o problema, mostrando os

objetivos a serem alcançados e a solução proposta.

A seção de Fundamentação Teórica aborda os assuntos necessários para construir a solução

proposta. São demonstradas as principais arquiteturas e conceitos existentes na área de gerência de

redes bem como a plataforma em que se deseja programar a solução, o Mono, traçando um

comparativo simplificado entre este e a implementação de referência da Microsoft.

A terceira seção aborda o projeto de software, que descreve os requisitos funcionais,

requisitos não funcionais e as regras de negócio. Os diagramas do projeto escolhidos para esta

solução são exibidos e explicados, bem como a importância de contemplá-los em um projeto de

software.

A seção de Desenvolvimento aborda os principais aspectos a serem descritos durante a

construção de toda a solução proposta. A criação de bibliotecas, estudos mais aprofundados e testes

são documentados nesta sessão.

A última etapa exibe as conclusões tiradas sobre este trabalho de conclusão de curso.

Page 17: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

2 FUNDAMENTAÇÃO TEÓRICA

A fundamentação teórica deste trabalho irá abordar os seguintes temas: (i) .NET Framework

e Projeto Mono; (ii) protocolos, arquiteturas e conceitos de gerência de redes; (iii) protocolo de

gerência de rede SNMP; (iv) descrição das ferramentas de monitoramento de código aberto.

2.1 .NET Framework e Projeto Mono

Nas seções seguintes, serão exibidos os estudos do .NET Framework e uma implementação

alternativa e de código aberto, o Projeto Mono.

2.1.1 .NET Framework

.NET é a plataforma criada pela Microsoft no final dos anos 90 utilizando o nome NGWS

(Next Generation Windows Services – Nova Geração de Serviços Windows), entretanto, foi no ano

2000 que a Microsoft liberou a primeira versão beta do .NET 1.0. O .NET fornece uma nova API

(Application Programming Interface – Interface de Programação de Aplicativos), com novas

funcionalidades, novas ferramentas para a construção de aplicações para o Microsoft Windows e

Web, novos componentes e novos serviços (TEMPLEMAN; VITTER, 2002, tradução nossa).

Uma nova API se tornou necessária para aplicações Windows, pelo fato de que sua API foi

escrita em C e cresceu com o passar dos anos. Atualmente, a API do Windows possui milhares de

rotinas e vários problemas, já que os novos recursos da API foram adicionados pouco a pouco e

com pouca organização. O fato de que a API do Windows seja construída em C acaba dificultando

o desenvolvimento em outras linguagens, inclusive em linguagens mais modernas orientadas a

objetos (IBIDEM).

Várias linguagens podem ser utilizadas para se desenvolver na plataforma .NET, entres as

quais o C#, Visual Basic .NET e J# se destacam. As aplicações desenvolvidas com essas linguagens

são compiladas para o IL (Intermediate Language – Linguagem Intermediária), que se assemelha ao

bytecode do Java. Isto significa que ao se desenvolver usando Visual Basic.NET, C# ou qualquer

outra linguagem suportada, a aplicação será compilada para a mesma linguagem, a IL.

Com a aplicação já compilada para a IL, é necessário um mecanismo para executá-la. Este

mecanismo é o CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução).

Page 18: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

7

O CLR dispõe de vários recursos como, JIT (Just in Time Compilation – Compilação em tempo de

execução), responsável por traduzir o IL em código nativo, Garbage Collection (coleta de lixo),

políticas de segurança e serviços de depuração. Com estes recursos, o CLR se situa entre o sistema

operacional e a aplicação, provendo a segurança e controlando o acesso à memória, permitindo

acesso transparente aos serviços do sistema operacional.

A plataforma .NET possui sua própria biblioteca de classes (BCL - Base Class Library).

Conforme Templeman e Viter (2002, tradução nossa), a BCL não é especifica para uma única

linguagem, podendo ser utilizada por qualquer linguagem que será compilada para a IL. Além

disso, a BCL é orientada à objetos, disponibilizando suas funcionalidades através de um grande

número de classes organizadas em vários namespaces1.

A BCL fornece ao desenvolvedor os seguintes itens:

• Definição de tipos básicos como int, char, entre outros.

• Tipos de coleção genéricos como vetores, listas, pilhas, tabelas hash, enumeradores e

filas.

• As classes podem definir suas exceções usando a BCL, sendo possível gerar uma

exceção usando C# e tratá-la usando VB.NET.

• Classes para tratamento do console, arquivos, entrada e saída, sockets, etc.

• Classes para desenvolver interfaces gráficas, desenhos em duas dimensões, tratamento

de imagens e impressão.

• Serialização de objetos, um modo de salvar os objetos que estão na memória em um

arquivo XML ou binário. Também possibilita carregar os objetos de um arquivo.

• Classes que implementam e gerenciam segurança.

• Classes para construção de aplicações distribuídas e sistemas Web.

• Classes para lidar com XML.

• Utilização de recursos do Sistema Operacional como threads (processos), timers, etc.

1 Namespaces são utilizados para organizar classes.

Page 19: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

8

O recurso de compilação Just in Time da arquitetura .NET permite que o código IL seja

portável e eficiente. A eficiência é garantida quando o código IL é compilado para o código nativo

em tempo de execução. Neste modo, a compilação ocorre quando o método é executado pela

primeira vez, e nas suas execuções seguintes, ele já executará o código nativo. Outro modo de

funcionamento do JIT é a compilação em tempo de instalação. Além disso, segundo Templeman e

Vitter (2002, tradução nossa), a plataforma .NET será portável assim que a IL seja suportada em

outros sistemas operacionais.

O recurso de Garbage Collection (coleta de lixo), é um recurso bastante útil presente na

plataforma .NET. Ele elimina problemas presentes em linguagens como o C, na qual os

programadores tem que desalocar manualmente a memória. O gerenciamento manual de memória

pode gerar grandes problemas. Caso o programador esqueça de desalocar a memória ou a desaloque

mais de uma vez, o programa poderá gerar erros. (TEMPLEMAN; VITTER, 2002, tradução nossa).

A disposição dos itens da arquitetura .NET são exibidos na Figura 1.

Figura 1. A Arquitetura .NET.

Fonte: Templeman e Vitter (2002).

Uma alternativa aos desenvolvedores .NET é o projeto de código aberto Mono. Ele suporta

praticamente as mesmas linguagens que o .NET Framework suporta e, pode ser executado em

vários Sistemas Operacionais baseados em Unix, além de Mac OS X e o próprio Windows.

Page 20: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

9

2.1.2 Projeto Mono

Mono é uma implementação multi-plataforma e de código aberto do .NET Framework.

Neste projeto, o principal compilador é destinado à linguagem C#, já que esta foi desenvolvida

especialmente pela Microsoft no .NET Framework. Entretanto, conforme Bornstein e Dumbill

(2004, tradução nossa), existem compiladores para o Mono com outras linguagens como Java, C,

Basic e Cobol.

A CLR (Common Language Runtime - Linguagem Comum de Tempo de Execução) faz

parte do projeto, garantindo que a aplicação rode de modo seguro, evitando travamentos,

desperdícios de memória e garantindo um alto desempenho. As vantagens do Just In Time Compiler

já mencionadas, também estão presentes no projeto Mono.

Assim como na plataforma .NET, no Mono uma aplicação é compilada para a IL

(Intermediate Language – Linguagem Intermediária). Isto garante a portabilidade da aplicação, já

que o Mono pode ser instalado nos sistemas operacionais Linux, Solaris, Mac OS X, Windows e

Unix (MONO, 2008, tradução nossa).

Para executar o mesmo software em sistemas operacionais diferentes, algumas práticas

devem ser adotadas, já que nem todos eles foram criados da mesma forma (BORNSTEIN;

DUMBILL, 2004 tradução nossa). A primeira delas trata da diferença no caractere separador de

diretórios quando se está trabalhando com arquivos. A Figura 2 demonstra estas diferenças.

String directory = “tmp”; String filename = “thefile”; //Modo incorreto String filePath = directory + “/” + filename; //Modo correto 1 String filePath = System.IO.Path.Combine(directory, filename); //Modo correto 2 String filePath = directory + System.IO.Path.DirectorySeparatorChar + filename;

Figura 2. Tratamento de arquivos para sistemas multi-plataforma.

Fonte: Adaptado de Bornstein e Dumbill (2004).

No mesmo contexto de arquivos, ainda existem problemas ao se trabalhar com o diretório raiz. No

sistema operacional linux, existe apenas um diretório raiz o /. No Windows, podem existir vários

diretórios sendo diferenciados por letras (C:\, D:\, ...). Para contornar este problema, pode-se utilizar

o método System.IO.Directory.GetLogicalDrives(), que retornará uma ou mais Strings contendo os

Page 21: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

10

diretórios raízes do sistema operacional. Além disto, deve-se ressaltar que alguns sistemas

operacionais são sensíveis à caixa (como o Linux) e outros não (como o Windows).

Outro problema é a definição de qual módulo de interface gráfica (GUI) utilizar. Para o

Mono, pode-se utilizar os módulos GTK#, Qt#, System.Windows.Forms entre outros. Cada um

deles é recomendado para diferentes sistemas operacionais e/ou ambientes gráficos. O GTK# é

principalmente destinado para ser utilizado no Gnome além de ter boa compatibilidade com o

Windows de 32 bits, demonstrado pelas Figura 3 e Figura 4 (SCHÖNIG; GESCHWINDE, 2003,

tradução nossa). Já o System.Windows.Forms é o mais recomendável para o uso no Windows, e é

compatível com as versões x86 do linux (BORNSTEIN; DUMBILL, 2004, tradução nossa).

Figura 3. GTK# no Linux.

Figura 4. GTK# no Windows.

Outro ponto crítico é quando se trata das configurações de cada aplicação desenvolvida. Em

aplicativos para Windows, na maioria das vezes, as aplicações guardam suas configurações no

registro, não presente em outros sistemas operacionais. Portanto, não se pode desenvolver

Page 22: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

11

aplicações que utilizam o registro do Windows, caso o objetivo a ser alcançado seja a portabilidade

do aplicativo (IBIDEM).

Existem outros tipos de compatibilidades e para lidar com elas faz-se necessário uma

codificação específica para cada plataforma. A detecção de diferentes plataformas através do código

fonte é demonstrada pela Figura 5. Utilizando o atributo VersionString, é possível utilizar if ou

switch-case para separar códigos de diferentes sistemas operacionais.

using System; using System.Diagnostics; namespace soDetection { class MainClass { public static void Main(string[] args) { OperatingSystem os = Environment.OSVersion; Console.WriteLine(os.VersionString); } } }

Figura 5. Código fonte para detecção de plataforma.

Fonte: Adaptado de Bornstein e Dumbill (2004).

Os resultados da execução do código da Figura 5 são exibidos pelas Figura 6 para o sistema

operacional Linux e Figura 7 para o Windows XP Service Pack 3.

Figura 6. Resultado da detecção do sistema operacional no Linux.

Figura 7. Resultado da detecção do sistema operacional no Windows XP.

Page 23: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

12

Mono é uma boa alternativa para os desenvolvedores, entretanto, ele não possui todas as

classes do .NET Framework disponíveis. A Figura 8 mostra os estados das partes do namespace

System, o maior e mais utilizado.

Figura 8. Status do desenvolvimento do namespace System.

Fonte: Mono (2008).

2.2 Modelos, arquiteturas e protocolos de gerência

Atualmente existem várias arquiteturas, modelos e protocolos de monitoramento de redes

propostos por várias organizações em todo o mundo. Uns são utilizados em larga escala enquanto

outros não passam de conceitos. As arquiteturas, modelos e protocolos de gerência direcionados às

redes de dados serão mostrados nos sub-tópicos seguintes.

2.2.1 Conceitos

O ambiente de gerenciamento OSI (Open Systems Interconnection – Interconexão de

Sistemas Abertos) de redes possui os conceitos de Gerente, Agentes e Objetos Gerenciados. O

Gerente possui a capacidade de receber notificações, informações e realizar ações de controle sobre

Page 24: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

13

os Objetos Gerenciados. Um objeto gerenciável é qualquer recurso que está sujeito a ações de

gerenciamento, como uma conexão, uma interface de rede ethernet ou uma porta de roteador, etc. O

Agente executa operações de gerenciamento sobre os objetos gerenciados, como desligar a interface

11 do switch ou solicitar a quantidade de octetos que trafegaram na referida porta. Neste ambiente,

aplica-se o protocolo CMIP (TAROUCO et al, 1993).

No ambiente de gerenciamento das redes interligadas à Internet, aplica-se o protocolo

SNMP (Simple Network Management Protocol – Protocolo Simples de Gerencia de Redes). Este

ambiente é bastante semelhante ao de gerenciamento OSI, pois a maioria dos conceitos abordados é

comum a ambos. Entretanto, a organização da árvore de objetos gerenciados é diferente (IBIDEM).

A MIB (Managed Information Base – Base de Informações Gerenciais) é um conjunto de

objetos gerenciados. Seu conceito é empregado tanto no padrão OSI quanto no Internet (IBIDEM).

A organização de objetos na MIB é feita seguindo um conjunto de regras definidos na SMI

(Structure of Managed Information – Estrutura de Informações Gerenciais). O acesso aos dados dos

objetos é feito utilizando a notação ISO ASN.1 (Abstract Syntax Notation, One- Notação de Sintaxe

Abstrata, Um). Para identificar um objeto, utiliza-se o OID (Object Identifier – Identificador de

Objeto) que são números separados por pontos. A Figura 9 ilustra o início da árvore do ambiente de

gerenciamento Internet (MAURO; SCHMIDT, 2001, tradução nossa).

Figura 9. MIB do ambiente de gerenciamento Internet.

Fonte: Adaptado de TAROUCO et al (1993) e MAURO e

SCHMIDT (2001).

Page 25: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

14

Para o Objeto “Management”, o OID resultante seria .1.3.6.1.2. Todo objeto gerenciável

deste modelo iniciará com o identificador exemplificado. Segundo Mauro e Schmidt (2001,

tradução nossa), “O Nó Raiz não possui qualquer nome ou número”. A descrição da SMI Internet

será aprofundada adiante.

Neste sub-seção, foram explicados os conceitos necessários para o entendimento dos sub-

seções seguintes.

2.2.2 FCAPS: Fault, Configuration, Accounting, Performance and Security

FCAPS é um modelo de gerência de redes definido por ITU-T que era direcionado a área de

telecomunicações. A ISO (International Standards Organization – Organização de Padrões

Internacionais) foi a entidade responsável por aplicar a FCAPS em redes de dados. Este modelo

divide a gerência em cinco áreas funcionais (NETWORKDICTIONARY, 2008a, tradução nossa):

• Fault Management (gerência de falhas): serve para detectar, criar registros, notificar os

usuários e até consertar possíveis erros fazendo com que a rede continue funcionando.

Ao ocorrer um erro, uma mensagem o gerente de rede pode ser avisado, através de um

protocolo de gerência de redes como o SNMP.

• Configuration Management (gerência de configurações): serve para monitorar a rede, as

configurações do sistema, além das várias versões de hardware e software. A

importância deste item aumenta conforme o tamanho da rede.

• Accouting Management (gerência de contas): a medição da utilização da rede pode ser

monitorada de forma individual ou por grupo. Além disto, pode-se detectar se a rede está

sendo utilizada para o propósito correto. Alguns dos itens que podem ser monitorados

são: uso de CPU, link e disco. Para este propósito, um protocolo bastante utilizado é o

RADIUS.

• Performance Management (gerência de desempenho): as variáveis que compõem a

medição do desempenho de uma rede são a vazão (throughput) da rede, os tempos de

resposta e a taxa de utilização da rede. Este item trata justamente desta medição.

• Security Management (gerência de segurança): este item trata da segurança da rede,

garantindo que as informações que trafegam nela sejam acessadas apenas por pessoas

autorizadas, além de evitar que a rede sofra algum tipo de ataque.

Page 26: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

15

O modelo FCAPS é uma extensão de um framework conceitual de gerencia de redes

chamado TMN (Telecommunications Management Networks – Gerência de Redes de

Telecomunicações), no qual também se identificam as mesmas cinco áreas de funcionais de

gerenciamento, com pequenas alterações (IBIDEM).

O objetivo do TMN é:

...prover uma estrutura organizada para interconectar vários tipos de Sistemas de Suporte à Operação e equipamentos de telecomunicações para a troca de informações de gerenciamento de interfaces padronizadas que incluem a definição de protocolos e mensagens (TAROUCO et al, 1993).

O FCAPS define várias regras que abordam os principais aspectos da gerência de redes.

Outra abordagem que mescla diversos aspectos das práticas de gerência apresentadas é o CMIP.

2.2.3 CMIP/CMISE

CMIP (Common Management Information Protocol – Protocolo de Gerência de

Informações Comuns) que é um protocolo da ISO (International Standards Organization –

Organização Internacional de Padrões) e é utilizado em conjunto com o CMIS (Common

Management Information Services – Serviço de Gerência de Informações Comuns). Este padrão em

conjunto com o padrão SNMP são os mais importantes (Networkdictionary, 2008a, tradução nossa).

Conforme Kurose e Ross (2007), o CMIP foi projetado para ser independente de produtos ou

fabricantes específicos e inicialmente era concorrente do protocolo SNMP.

Tanto CMIP quanto CMISE também são utilizados na arquitetura CMOT (Common

Management over TCP/IP – Gerenciamento comum sobre TCP/IP) (TAROUCO et al, 1993) ou

(CMIP over TCP/IP – CMIP sobre TCP/IP) (MILLER, 1997, tradução nossa). O CMOT é baseado

na estrutura de gerenciamento OSI e nos modelos, serviços e protocolos desenvolvidos pela OSI

para gerenciamento de redes (TAROUCO et al, 1993).

Conforme o Networkdictionary (2008b, tradução nossa), o CMIS define um sistema de

gerência de redes, já o CMIP supre a necessidade da existência de uma interface que provê funções

que podem ser utilizadas tanto por protocolos de gerência de redes que estão conformes com a ISO

e até por protocolos customizados.

CMIP utiliza o mecanismo de transporte orientado à conexão já que utiliza o protocolo TCP.

Isto pode ser considerado uma desvantagem, já que se um dispositivo de rede estiver com

Page 27: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

16

problemas, o software de gerência só poderá receber dados do dispositivo após efetuar uma conexão

com este. Apesar disso, este protocolo possui embutido um sistema de segurança que suporta

controle de acesso, autorização e gravação de registros. Quando aplicado na arquitetura CMOT, o

CMIP pode ser utilizado com o protocolo LPP (Lightweight Presentation Protocol – Protocolo de

Apresentação Simples). Neste caso, devido o uso do LPP, o CMIP poderá rodar tanto no protocolo

TCP quanto no UDP, conforme em Tarouco et al (1993):

O CMOT deixa a escolha de TCP ou UDP para a aplicação de gerenciamento. Os sistemas dentro de um ambiente de LAN (Local Area Network – Rede local) são melhor servidos pela escolha do UDP, enquanto os sistemas em um ambiente WAN (Wide Area Network – Rede de longa distância) deveriam escolher TCP.

O protocolo CMIP de modo algum especifica o software de gerenciamento, apenas define

como será a comunicação entre agentes e o software (Networkdictionary, 2008b, tradução nossa).

Este esquema de comunicação é mostrado na Figura 10.

Figura 10. Sistema de gerenciamento baseado em CMIP/CMIS.

Fonte: Adaptado de Networkdictionary (2008b).

Conforme Networkdictionary (2008b, tradução nossa), o CMIP possui vantagens quando

comparado ao SNMP:

Page 28: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

17

• CMIP além de obter informações, pode realizar tarefas, o que é impossível no SNMP.

• Possui segurança embutida.

• Provê recursos poderosos que permitem aplicações gerenciais de realizarem mais tarefas

com uma única requisição.

• Em redes em condições incomuns, ele gerará relatórios melhores.

O acesso de informações gerenciais em objetos gerenciáveis é feito através do CMISE

(Common Management Information Service Element – Elemento do Serviço de Gerência de

Informações Comuns), o qual utiliza o CMIP para requisitar informações (TAROUCO et al, 1993).

Por último, é revisado o SNMP, protocolo para a gerência que se consolidou com o advento

da Internet.

2.2.4 SNMP

O SNMP (Simple Network Management Protocol – Protocolo Simples para o

Gerenciamento de Redes) é um protocolo de gerência de redes. Foi introduzido em 1988 para suprir

uma necessidade crescente de gerenciamento de dispositivos que utilizam o protocolo IP (Internet

Protocol) como roteadores, switches, modems, access points, etc. Seu coração é um conjunto

simples de operações que permite aos softwares de gerência relatarem os dados de dispositivos de

rede suportados. Por exemplo, pode-se utilizar SNMP para desligar uma interface de um roteador

ou checar a velocidade da interface Ethernet. SNMP pode ainda monitorar a temperatura de um

switch e até gerar um alerta se esta ficar muito alta (MAURO; SCHMIDT, 2001, tradução nossa).

Existem atualmente três versões do protocolo SNMP (IBIDEM):

• SNMP versão 1 (SNMPv1): é a versão definida pelo RFC 1157 (RFC 1157, 1989),

padrão da IETF (Internet Engineering Task Force – Força Tarefa de Engenharia da

Internet). A segurança desta versão é baseada em comunidades, que nada mais são do

que senhas. Pode-se definir uma comunidade com acessos de somente leitura para

acessar apenas informações ou leitura e escrita que podem alterar configurações. Uma

terceira comunidade é chamada de trap.

• SNMP versão 2 (SNMPv2): esta versão é chamada tecnicamente de SNMPv2c. É

definida pelos RFC 1905 (RFC 1905, 1996), RFC 1906 (RFC 1906, 1996) e RFC 1907

Page 29: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

18

(RFC 1907, 1996). Segundo a IETF, ainda encontra-se em estado experimental,

entretanto, alguns fabricantes de equipamentos de rede já estão disponibilizando

equipamentos de rede com suporte desta versão.

• SNMP versão 3 (SNMPv3): ainda em estado experimental, a SNMPv3 terá vários

recursos novos como uma autenticação mais segura e comunicação privada entre

entidades gerenciadas. A versão é definida pelos RFC da versão 2 e os RFC 2571 (RFC

2571, 1999), RFC 2572 (RFC 2572, 1999), RFC 2573 (RFC 2573, 1999), RFC 2574

(RFC 2574, 1999) e RFC 2575 (RFC 2575, 1999).

O protocolo SNMP não é orientado a conexões como o CMIP, já que utiliza o protocolo

UDP (User Datagram Protocol – Protocolo de Datagrama do Usuário). Isto significa que o SNMP

possui um desempenho superior, já que não existe um overhead (sobrecarga) da conexão. Além

disso, o UDP não possui timeouts, este é programado diretamente no software de gerenciamento.

2.2.4.1 Gerenciadores e Agentes

O protocolo SNMP aplica os conceitos de gerente e agente (MILLER, 1997, tradução

nossa). O Gerenciador, também conhecido como NMS (Network Management Station – Estação de

Gerenciamento da Rede) se comunica com os agentes através de requisições chamadas polling

(teste e resposta). O Agente pode alertar o NMS quando utiliza os traps, que funcionam como

gatilhos que são disparados caso alguma condição seja alcançada (MAURO; SCHMIDT, 2001,

tradução nossa).

A Figura 11 mostra a relação entre o NMS e o Agente. Apesar de que a figura demonstre

ações de forma separada, o NMS pode realizar o polling e receber traps ao mesmo tempo.

Figura 11. Relação entre o NMS e o Agente.

Fonte: Adaptado de Mauro e Schmidt (2001).

Page 30: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

19

Assim como os agentes e o NMS, o conhecimento sobre a SMI e suas versões é primordial

para o entendimento do protocolo SNMP.

2.2.4.2 SMIv1

Cada versão do protocolo SNMP possui uma versão de SMI. Na SMI versão 1, a definição

de Objetos Gerenciáveis é composta por três itens:

1. Nome: é o que identifica o objeto gerenciável. Este item pode ser um nome ou o OID

(Object Identifier).

2. Tipo e sintaxe: O tipo do objeto é definido usando a sintaxe ASN.1. É um modo de

definir como os dados serão transmitidos entre gerenciadores e agentes. Os tipos de

objetos são parecidos com os da linguagem C. A Tabela 1 exibe os principais tipos.

3. Encoding (Codificação): Uma instância de um objeto gerenciado é codificada numa

string de octetos usando BER (Basic Encoding Rules – Regras Básicas de Codificação).

Tabela 1. Tipos de dados SMIv1

Tipo de dado Descrição Integer É um número inteiro de 32 bits, bastante utilizado para dados enumerados.

Para enumeração, o 0 não é considerado. Octect String É uma string (seqüência de caracteres) de octetos, usado para transmissão

de texto ou identificação física de uma interface de rede. Counter É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1.

Quando o valor máximo é atingido, ele volta para zero e recomeça. É utilizado para contagem de qualquer item, como quantidade de erros numa interface de redes ou octetos que trafegaram nesta interface. É um valor que sofre incrementação, sendo que uma decrementação ocorre apenas em casos de erros. Quando o agente é reiniciado, os dados do tipo Counter recebem zero.

Object Identifier O OID é definido por números decimais separados por pontos. Sequence Define uma lista de vários tipos de dados com sintaxe ASN.1, parecendo

uma tabela. Sequence of Define um objeto gerenciável feito com o tipo Sequence. IP Address É um valor de 32 bits que representa um IP versão 4. Ambas as SMIv1 e

SMIv2 não possuem suporte ao IP versão 6. Gauge É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1.

Diferente do Counter, este tipo pode decrementar normalmente. A velocidade de uma interface de um roteador é medida com Gauge.

TimeTicks É um valor de 32 bits com o valor mínimo zero e o máximo igual a 232-1. Este tipo mede o tempo em centenas de segundos. O uptime (tempo ligado) de um dispositivo é medido com este tipo.

Fonte: Adaptado de Mauro e Schmidt (2001).

Page 31: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

20

Como já mencionado, os objetos gerenciáveis estão dispostos na SMI numa estrutura em

árvore. É através desta árvore que se define o Object Identifier (identificador do objeto). A árvore

SMI com suas partes mais importantes é demonstrada na Figura 12.

Figura 12. A árvore de objetos da SMIv1.

Fonte: Adaptado de Mauro e Schmidt (2001).

2.2.4.3 MIB do SMIv1

Uma MIB é definida usando a sintaxe ASN.1. Conforme Mauro e Schmidt (2001), “É muito

importante que se saiba ler e entender uma MIB já que em alguns casos pode ser necessário

implantar uma ou parte dela”. Na Figura 13 é demonstrado o código de uma versão de uma MIB.

Os comentários são iniciados por -- .

RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC 1212; mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

Figura 13. Primeiras linhas de uma MIB.

Fonte: Mauro e Schmidt (2001).

As primeiras linhas de uma MIB foram apresentadas na Figura 13. Na primeira linha,

define-se o nome da MIB, que no caso é “RFC1213-MIB” (RFC 1213 – 1991). A sessão IMPORTS,

permite que sejam importados tipos de dados e OIDs de outras MIBs. No caso acima, foram

importados tipos de dados da RFC 1155 (RFC 1155, 1990) SMI (SMIv1), que incluem:

Page 32: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

21

• mgmt;

• NetworkAddress;

• IpAddress;

• Counter;

• Gauge; e

• TimeTicks.

Além disso, foi importado o Object Type RFC 1212 (RFC 1212, 1991), o qual define a

maneira de como a MIB foi escrita. A última linha da Figura 13 define o início dos OIDs dos

objetos gerenciáveis. Por ser mgmt, o OID equivalente é 1.3.6.1.2. Após a sessão de IMPORTS,

parte-se então para a definição dos objetos gerenciáveis (IBIDEM), que seguem o formato

demonstrado pela Figura 14.

<nome> OBJECT-TYPE SYNTAX <tipo de dado> ACCESS <pode ser read-only, read-write, write-only, ou not-accessible> STATUS <mandatory, optional, ou obsolete> DESCRIPTION "Descrição textual do objeto gerenciável." ::= { <Um OID único do objeto gerenciável.> }

Figura 14. Formato da declaração de objetos gerenciáveis.

Fonte: Mauro e Schmidt (2001).

Para exemplificar a definição de objetos gerenciáveis, utilizou-se o ifTable, que nada mais é

que uma lista de interfaces de rede num dispositivo gerenciável.

ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber." ::= { interfaces 2 }

Figura 15. Definição de objetos gerenciáveis.

Fonte: Mauro e Schmidt (2001).

A sintaxe deste objeto é SEQUENCE OF IfEntry, que é uma tabela que possui colunas que

são definidas pela IfEntry. O objeto está marcado como inacessível, portanto, não é possível fazer

com que o agente consulte este objeto. Seu status é mandatory (obrigatório) significando que o

agente precisa implementar este objeto para ser compatível com os padrões da especificação MIB-

Page 33: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

22

II. O campo Description (descrição) descreve o que é este objeto. Na última linha da Figura 15,

define-se o OID, que é 1.3.6.1.2.1.2.2 ou iso.org.dod.internet.mgmt.interfaces.2. Na Figura 16, é

demonstrado um trecho da definição da Sequence IfEntry.

IfEntry ::= SEQUENCE { ifIndex INTEGER, ifDescr DisplayString, ifType INTEGER, ifMtu INTEGER, (...) ifSpecific OBJECT IDENTIFIER }

Figura 16. Definição da Sequence IfEntry.

Fonte: Mauro e Schmidt (2001).

Na definição da Sequence nota-se que seu nome começa com letra maiúscula, diferente de

quando se define um objeto gerenciável. Como uma Sequence se parece com uma tabela, nesta

esperamos encontrar todos os tipos descritos em sua definição. A adição de novos registros também

pode ser feita pelo NMS (MAURO; SCHMIDT, 2001, tradução nossa).

2.2.4.4 SMIv2 e sua MIB

A SMIv2 adiciona novos itens à arvore de objetos gerenciáveis além de mais tipos de dados.

A principal novidade é o ramo snmpV2, que possui o OID 1.3.6.1.6.3.1.1.. A Figura 17 exibe a

SMIv2.

Figura 17. SMIv2 e novos ramos.

Fonte: Mauro e Schmidt (2001).

Page 34: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

23

Os novos tipos de dados incluídos na SMIv2 estão na Tabela 2.

Tabela 2. Novos tipos de dados da SMIv2

Tipo de dado Descrição Integer32 Mesmo que Integer (inteiro). Counter32 Mesmo que Counter (contador). Gauge32 Mesmo que Gauge. Unsigned32 Representa um valor decimal que vai de 0 até 232-1. Counter64 Similar ao Counter32, entretanto seu valor máximo é

18.446.744.073.709.551.615. Sendo seu valor máximo bem alto, este tipo se torna ideal para contadores que podem ser reiniciados antes do tempo desejado.

BITS Uma enumeração de bits não negativos.

Fonte: Adaptado de Mauro e Schmidt (2001).

Na SMIv2 também houve mudanças na especificação dos objetos gerenciáveis através da

adição de novos campos adicionais. Estes campos permitem que os objetos sejam descritos de

melhor maneira. A nova estrutura de descrição de objetos segue o modelo exibido na Figura 18.

<nome> OBJECT-TYPE SYNTAX <tipo de dado> UnitsParts <Opcional, veja descrição na Tabela 3> MAX-ACCESS <Opcional> STATUS <Ver descrição na Tabela 3> DESCRIPTION "Descrição textual deste objeto gerenciável." AUGMENTS { <nome da tabela> } ::= { <O OID que representa este objeto.> }

Figura 18. Definição de objetos gerenciáveis na SMIv2.

Fonte: Mauro e Schmidt (2001).

Cada trecho dos aprimoramentos demonstrados na Figura 18, é descrito na Tabela 3.

Tabela 3. Aprimoramentos na definição de objetos.

Aprimoramento Descrição UnitsParts Uma descrição textual da unidade usada (segundos, milisegundos). MAX-ACCESS É um aprimoramento do ACCESS da SMIv1 (que também pode ser

utilizado nesta versão). A diferença, são os novos valores suportados: read-only (somente leitura), read-write (leitura e escrita), read-create (leitura e criação), not-accessible (não acessível) e accessible-for-notify (acessível para notificação).

STATUS Esta clausula foi extendida para permitir os valores current, obsolete e deprecated. O valor current tem o mesmo significado que mandatory da SMIv1.

Page 35: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

24

Augments É utilizado em casos em que é importante adicionar uma ou mais colunas novas a uma tabela. Esta clausula necessita que seja especificado o nome da tabela que terá colunas adicionadas.

Fonte: Adaptado de Mauro e Schmidt (2001).

Na SMIv2 também são introduzidos novas convenções textuais, termos que fazem com que

o objeto gerenciável seja declarado de um modo mais abstrato. Os novos termos são definidos na

RFC 2579 (RFC 2579, 1999). A Tabela 4 apresenta esses termos.

Tabela 4. Novos termos

Convenção Textual Descrição DisplayString É uma seqüência de caracteres NVT ASCII, e não pode ultrapassar

255 caracteres. PhysAddress Endereço físico ou da camada de enlace representado por uma cadeia

de octetos. MacAddress É o endereço MAC da interface de rede, definido por seis octetos,

sendo que o bit menos significante é o primeiro. TruthValue É um tipo booleano que recebe true (verdadeiro) ou false (falso). TestAndIncr Utilizado para evitar problemas quando duas estações de

gerenciamento modificam um único valor ao mesmo tempo. AutonomousType É um OID utilizado para definir um novo ramo na árvore da MIB. VariablePointer É um ponteiro para uma instância qualquer de um objeto gerenciável.

Este ponteiro contém o OID da instância. RowPointer É um ponteiro para uma tupla de uma tabela. RowStatus Usado para gerenciar a inserção e exclusão de tuplas numa tabela,

garantindo a integridade desta tabela. RowStatus pode receber os valores active(1)(ativo), notInService(2)(fora de serviço), notReady(3)(fora de prontidão), createAndGo(4)(criar e continuar), createAndWait(5)(criar e esperar) e destroy(6)(destruir).

TimeStamp Mede o tempo que passou desde que o dispositivo foi ligado até o momento de alguma ocorrência.

TimeInterval Mede um período de tempo em centenas de segundos, podendo receber valores de 0 até 2147483647.

DateAndTime É um Octect String utilizado para representar a data e o horário. StorageType Define o tipo de memória que o agente está utilizando. Os valores

possíveis são other(1), volatile(2), nonVolatile(3), permanent(4) e readOnly(5).

TDomain Fornece o tipo de serviço de transporte. TAddress Fornece o endereço do tipo de transporte. Seu tamanho pode ser de 1

até 255 octetos.

Fonte: Adaptado de Mauro e Schmidt (2001).

Page 36: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

25

2.2.4.5 MIB-II

MIB-II é um importante grupo de gerenciamento, porque todos os dispositivos que suportam

SNMP também suportam este grupo (MAURO; SCHMIDT, 2001, tradução nossa). MIB-II é um

ramo da árvore SMI, o qual deriva do nó mgmt(2). A Figura 19 demonstra graficamente o ramo

MIB-II.

Figura 19. MIB-II.

Fonte: Adaptado de Mauro e Schmidt (2001).

A Tabela 5 explica brevemente cada item desta sub-árvore.

Tabela 5. Explicação dos ramos da MIB-II

Ramo OID Descrição System 1.3.6.1.2.1.1 Alguns dos itens mais importantes deste são o uptime do

sistema, contato do administrador e o nome do sistema. Interfaces 1.3.6.1.2.1.2 Possui informações sobre o estado de cada interface de rede

como, octetos enviados, octetos recebidos, se está ligada ou desligada, etc.

At 1.3.6.1.2.1.3 Este ramo só existe para manter a compatibilidade com versões mais antigas de algumas aplicações. Este ramo trata de tradução de endereços.

Ip 1.3.6.1.2.1.4 Possui várias informações sobre vários aspectos do protocolo IP, incluindo roteamento.

Icmp 1.3.6.1.2.1.5 Possui informações sobre o ICMP, como erros e descarte de pacotes.

Tcp 1.3.6.1.2.1.6 Rastreia, entre outros itens, o estado de uma conexão TCP. Udp 1.3.6.1.2.1.7 Com ele é possível construir estatísticas sobre o protocolo

UDP, contendo informações como a quantidade de pacotes que entraram e saíram.

Egp 1.3.6.1.2.1.8 Possui dados sobre o protocolo EGP (Exterior Gateway

Protocol – Protocolo de gateway externo).

Page 37: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

26

transmission 1.3.6.1.2.1.10 Este ramo é raramente utilizado, sendo que é utilizado em MIBs de dispositivos mais específicos.

Snmp 1.3.6.1.2.1.11 Possui dados sobre o protocolo SNMP no dispositivo que está sendo gerenciado, como a quantidade de pacotes SNMP enviados e recebidos, traps, etc.

Fonte: Adaptado de Mauro e Schmidt (2001).

2.2.4.6 Operações do protocolo SNMP

No protocolo SNMP e em suas versões, existem as seguintes operações ou PDU’s (Protocol

Data Unit – Unidade de Dados do Protocolo) (MILLER, 1997, tradução nossa): get, get-next, get-

bulk, set, get-response, trap, notification, inform, report (MAURO; SCHMIDT, 2001, tradução

nossa). Algumas das principais operações são descritas a seguir.

Operação get

Esta operação é iniciada apenas pelo NMS e ocorre quando este necessita de alguma

informação do dispositivo que está sendo gerenciado. Ao fazer a requisição o OID do objeto é

passado como um parâmetro. Em casos em que o dispositivo está com sobrecarga de

processamento, é possível que o dispositivo descarte o pacote (MAURO; SCHMIDT, 2001,

tradução nossa). Esta operação está disponível em todas as versões do SNMP. A resposta do agente

é adquirida utilizando a operação get-response (MILLER, 1997, tradução nossa).

Operação get-next

Esta operação tem o seu funcionamento semelhante ao da operação get. Entretanto, esta

operação é utilizada para receber um grupo de informações. A operação get-next navega na árvore

utilizando a técnica top-down (MAURO; SCHMIDT, 2001, tradução nossa).

Operação get-bulk

Esta operação está disponível apenas nas versões 2 e 3 do SNMP (IBIDEM). get-bulk

permite que o NMS requisite um grande número de dados de um objeto gerenciável. É uma

operação que também se assemelha a operação get. Entretanto, a operação get gera erros ao

requisitar um grande número de dados em casos em que o dispositivo esteja muito ocupado. Mas no

caso do get-bulk, segundo MILLER (1997, tradução nossa) e MAURO e SCHMIDT (2001,

tradução nossa), a operação evita este erro, retornando dados incompletos.

Page 38: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

27

Operação set

A operação set está disponível em todas as versões do SNMP. Esta é utilizada para alterar o

valor de um objeto gerenciável ou criar uma nova tupla em uma tabela, dependendo é claro, das

permissões (MILLER, 1997, tradução nossa).

Traps

Trap é a maneira utilizada pelo agente de comunicar o NMS de um evento ocorrido. O

agente possui configurado quem é o destinatário destas traps, sendo que geralmente é configurado o

IP do NMS (MAURO; SCHMIDT, 2001, tradução nossa). Existem seis tipos genéricos de traps,

conforme a Tabela 6.

Tabela 6. Tipos de traps

Tipo Descrição coldStart(0) Indica que o agente foi reiniciado. Todos os objetos gerenciáveis do

tipo Counter e Gauge são zerados. warmStart(1) Indica que o agente se reiniciou. Neste caso nenhum objeto

gerenciável é alterado. linkDown(2) É enviado caso alguma interface do dispositivo foi desconectada ou

desligada. linkUp(3) É enviado caso alguma interface do dispositivo foi conectada ou

ligou. authenticationFailure(4) Indica que alguém tentou fazer alguma requisição ao agente e ele

negou devido a uma falha de autenticação. egpNeighborLoss(5) Indica a perda de conexão com um vizinho que utiliza o protocolo

EGP. enterpriseSpecific(6) Esta trap é configurada ou especificada de acordo com o fabricante

do dispositivo. Nestes casos, o NMS necessita decodificar a trap.

Fonte: Adaptado de Mauro e Schmidt (2001).

2.3 Softwares de monitoramento

Os sistemas de monitoramento descritos nesta seção servirão como fonte de requisitos para a

construção de um novo sistema. Os softwares escolhidos são: Nagios (NAGIOS, 2008) e Cacti

(CACTI, 2008), que são bastante utilizados atualmente.

2.3.1 Nagios

Nagios (NAGIOS, 2008) é um software de monitoramento de hosts e de serviços, construído

para informar o administrador de problemas antes que estes sejam detectados pelo usuário final. Foi

Page 39: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

28

desenvolvido inicialmente para rodar em Linux, mas atualmente ele roda em qualquer sistema

baseado em Unix. Para realizar os mais diversos tipos de monitoramento, Nagios faz uso de plugins,

que são específicos para cada tipo de monitoramento. O daemon (espécie de serviço) do Nagios

ativa estes plugins para que eles coletem as informações necessárias e assim as retorna para ele.

O Nagios utiliza plugins para realizar o monitoramento sendo, portanto, um software

bastante flexível, já que o administrador pode construir facilmente plugins específicos para um dado

tipo de aplicação. Aplicações já conhecidas e bastante utilizadas já possuem plugins construídos

(BURGESS, 2005, tradução nossa). A Tabela 7 possui uma lista dos principais plugins.

Tabela 7. Lista dos principais plugins do Nagios

Plugin Descrição check_http Este plugin testa os serviços de HTTP (Hypertext Transfer Protocol

– Protocolo de transferência de hipertexto) em um host específico. Ele suporta o HTTP assim como o HTTPS (Hypertext Transfer

Protocol Secure – Protocolo de transferência de hipertexto seguro). Além disto, ele pode consultar redirecionamentos, buscar por expressões regulares, medir o tempo de conexão e verificar se algum certificado está para expirar.

check_dns Este faz uso do software nslookup (já disponível em grande parte dos Sistemas Operacionais) para verificar se o servidor DNS (Domain Name Server – Servidor de Nomes de Domínios) especificado pode traduzir o domínio para um endereço IP.

check_dhcp Utilizado para testar a disponibilidade de um dado servidor DHCP (Dynamic Host Configuration Protocol – Protocolo de Configuração Dinâmica de Hosts).

check_disk Utilizado para verificar a quantidade de espaço em disco disponível. Ele pode gerar um alerta caso o valor crítico (configurável) seja alcançado.

check_dummy Ao invés de verificar o estado de um serviço, este plugin retorna valores estipulados pelo administrador.

check_imap Faz a verificação de uma conexão IMAP (Internet Message Access

Protocol – Protocolo de Acesso para Mensagens da Internet). check_mysql Faz um teste de conexão com um banco de dados MySQL. check_mysql_query Um plugin para teste de banco de dados MySQL mais elaborado.

Este executa uma consulta no banco de dados, e o valor retornado é comparado com o valor aceitável configurado, podendo emitir alertas caso o valor aceitável seja ultrapassado.

check_nntp Faz um teste de conexão com um host que possui NNTP (Network

News Transfer Protocol – Protocolo de Transferência de Notícias pela Rede).

check_procs Faz uma checagem de todos os processos em um host e pode gerar avisos e alertas críticos caso alguma métrica esteja fora dos parâmetros configurados.

Page 40: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

29

check_ping Faz o uso de ICMP (Internet Control Message Protocol – Protocol de Mensagens de Controle da Internet) para construir estatísticas de conexão com um determinado host.

check_smtp Este plugin simplesmente tentará abrir uma conexão com um servidor SMTP (Simple Mail Transfer Protocol - Protocolo de Simples Transferência de Emails).

check_tcp Faz um teste de uma conexão de TCP (Transfer Control Protocol – Protocolo de Controle de Transferência) qualquer com um determinado host.

check_udp Semelhante ao check_tcp, mas testa com o protocolo UDP (User

Datagram Protocol – Protocolo Livre de Datagrama). check_nt Este plugin coleta uma informação específica do serviço NSClient

rodando em hosts que estão rodando com Windows NT/2000/XP/2003. A informação que se deseja é um parâmetro a ser passado.

Com os plugins necessários instalados, pode-se então iniciar o monitoramento. É possível

instalar o Nagios já pré-configurado, de modo que ele já monitore a máquina em que está rodando e

o seu gateway. Nagios é configurado utilizando arquivos texto, e os arquivos padrões são exibidos

na Tabela 8.

Tabela 8. Arquivos padrões de configuração do Nagios

Arquivo Descrição nagios.cfg Contém configurações básicas como formato da data e hora. Por padrão,

este arquivo já vem configurado corretamente, bastando alteração de poucos parâmetros.

checkcommands.cfg Neste arquivo existem informações sobre os plugins e como eles serão utilizados.

misccommands.cfg É o arquivo que contém diversos tipos de comandos que podem ser executados, incluindo a configuração do comando de envio de alertas (por celular, email, etc).

timeperiods.cfg Neste arquivo é especificado quando o Nagios executará as verificações. cgi.cfg Contém as permissões dos usuários que acessarão as informações do

Nagios. contacts.cfg Este arquivo contém as definições de contatos para alertas e avisos. contactgroups.cfg Neste arquivo é possível construir grupos, especificando quais os contatos

fazem partes de cada grupo. hosts.cfg Este arquivo possui a lista e o modo de como os hosts serão monitorados.

Neste arquivo, cada host pode possuir especificado um endereço IP, um apelido, o seu nome, os comandos de checagem, etc.

hostgroups.cfg Neste arquivo é possível construir grupos de hosts, facilitando o monitoramento.

Com o Nagios configurado, pode-se então verificar os dados coletados. Para isto, basta

acessar a página do Nagios, que possui um endereço configurado na instalação, fornecendo o

Page 41: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

30

usuário e senha, também configurados no processo de instalação. A Figura 20 mostra a tela inicial

do Nagios.

Figura 20. Tela inicial do Nagios.

Fonte: Nagios (2008).

Page 42: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

31

Para visualizar o estado dos serviços, seleciona-se a opção Service Details (Detalhes dos

Serviços). A tela que surgirá apresenta os hosts com seus respectivos serviços e estados. Além

disso, é exibida uma descrição detalhada do estado do serviço. A Figura 21 demonstra esta tela.

Figura 21. Detalhes dos hosts.

Fonte: Nagios (2008).

Page 43: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

32

Para visualizar o estado dos hosts, é acessada a opção Host Detail (Detalhe do Host). Nesta

tela são exibidos todos os hosts com o respectivo estado e informações. A Figura 22 demonstra esta

tela.

Figura 22. Detalhes dos serviços.

Fonte: Nagios (2008).

Outro recurso interessante do Nagios é a exibição do Mapa da Rede (Network Map). Ele

consiste em exibir a topologia da rede graficamente, mostrando os computadores, roteadores, entre

outros hosts. Além disso, ele pode exibir qual Sistema Operacional o host está rodando, caso este

esteja especificado no arquivo “hosts.cfg”. A Figura 23 demonstra este recurso.

Page 44: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

33

Figura 23. Recurso “Mapa da Rede”.

Fonte: Nagios (2008).

O Nagios possui vários recursos poderosos, entretanto, ele não possui nenhuma forma de

construção de gráficos. Grande parte dos administradores de rede vem adotando o Cacti como um

software adicional para a produção destes gráficos.

2.3.2 Cacti

Cacti (CACTI, 2008) é uma interface completa para o RRDtool (Round Robin Database

Tool – Ferramenta para Bancos de Dados Round Robin), coletando todas as informações

necessárias para construir gráficos e as gravando em uma base no banco de dados MySQL. Ele é

totalmente construído com a linguagem PHP. As configurações são todas feitas na interface Web do

Cacti e estas são também armazenadas no banco de dados MySQL.

Page 45: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

34

O RRDtool é um padrão industrial OpenSource (código aberto) de alto desempenho para

armazenamento de informações e gráficos que representam dados temporais. Esta ferramenta pode

ser utilizada em conjunto com as linguagens PHP, Python, Perl, Ruby e TCL (OETIKER, 2008,

tradução nossa).

Para iniciar o uso do Cacti, basta acessar a URL na qual ele se encontra. Deve-se fornecer o

usuário “admin” e a senha “admin”, sendo que a senha deve ser alterada no primeiro acesso. A tela

inicial é demonstrada na Figura 24.

Figura 24. Tela inicial do Cacti.

Fonte: Cacti (2008).

Na parte superior da tela, o Cacti apresenta duas opções: console (gerência de configurações) e

graphs (gráficos). A tela inicial iniciará com a opção console já selecionada, e nesta opção é

possível cadastrar, alterar ou excluir algum dispositivo e/ou gráfico.

Page 46: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

35

A tela de cadastro e alteração de dispositivos de rede do Cacti é demonstrada na Figura 25.

Os campos a serem preenchidos são descritos a seguir, sendo que parte deles já é preenchida com

valores padrão.

• Description (descrição): deve ser preenchido com alguma informação útil sobre o

dispositivo.

• Hostname (nome do host): deve ser preenchido com o nome do dispositivo de rede ou

seu endereço IP.

• Host Template (modelo do host): deve-se selecionar em qual modelo o host se enquadra.

Os modelos já incluídos no Cacti são: Cisco Router (Roteador da marca Cisco), Generic

SNMP-enabled Host (Host genérico com SNMP ativo), Karlnet Wireless Bridge (Ponte

de rede sem-fio da marca Karlnet), Local Linux Machine (Máquina Local com sistema

operacional Linux), Netware 4/5 Server (Servidor Netware versão 4 ou 5), ucd/net

SNMP Host, Windows 2000/XP Host.

• Notes (notas): neste campo é possível cadastrar informações sobre o dispositivo já que é

um campo bastante grande.

• Disable Host (inativar host): este campo é selecionado caso deseja-se que o dispositivo

não seja verificado pelo Cacti.

• Downed Device Detection (Detecção de dispositivos desconectados/desligados): o modo

de como é feita a detecção do dispositivo na rede. Pode ser selecionado por Ping ou

desativar a detecção.

• Ping Method (método do ping): é o modo de como o ping será executado caso a opção

Downed Device Detection esteja marcada como ping. Pode-se executar o ICMP Ping,

TCP Ping e UDP Ping.

• Ping Port (porta para o ping): seleciona-se a porta para a qual o ping irá “disparar”.

Somente em casos de TCP Ping e UDP Ping.

• Ping timeout (tempo limite para resposta do ping): a métrica deste campo é em mili-

segundos.

• Ping Retry Count (número de tentativas de ping): é informada a quantidade máxima de

vezes em que é tentada a realização do ping.

Page 47: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

36

• SNMP Version (versão SNMP): neste campo pode-se selecionar entre as versões 1, 2 ou

3 do protocolo SNMP. Dependendo da versão selecionada, os campos seguintes se

alteram. Para exemplificar, foi selecionada a versão 2.

• SNMP Community (Comunidade SNMP): é preenchido o nome da comunidade SNMP

que foi configurada no agente do dispositivo. Já que o Cacti apenas coleta informações

dos dispositivos, uma comunidade com privilégios de apenas leitura é o suficiente.

• SNMP port (porta do SNMP): este campo é preenchido o número da porta em que o

agente SNMP do dispositivo está “escutando”.

• SNMP timeout (tempo limite do SNMP): preenchido com o tempo máximo de espera

pela resposta de uma requisição SNMP. O valor é em mili-segundos.

• Maximum OID’s per Get Request (quantidade máxima de OIDs por requisição): é

informada a quantidade máxima de OIDs que uma operação SNMP do tipo get pode

retornar.

Page 48: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

37

Figura 25. Cadastro e/ou alteração de um dispositivo de rede no Cacti.

Fonte: Cacti (2008).

Depois de preenchidos os campos, basta acionar o botão Create (criar) e o dispositivo é

cadastrado no banco de dados e então passa a ser monitorado.

Para visualizar os gráficos gerados pelo Cacti, basta selecionar a opção graphs no topo da

tela. A Figura 26 mostra esta visualização, exibindo apenas um gráfico, entretanto basta utilizar a

rolagem para mostrar os outros gráficos. No topo da tela existe um modo de montar o gráfico de

acordo com um período especificado. Inicialmente, o Cacti já preenche esses valores que exibem os

gráficos com base em dados das últimas 24 horas. No lado esquerdo da tela, é possível selecionar o

Page 49: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

38

dispositivo que se deseja visualizar os gráficos (neste caso existe apenas um). Abaixo de cada

gráfico, o Cacti apresenta estatísticas.

Figura 26. Visualizando gráficos no Cacti.

Fonte: Cacti (2008).

Com o Cacti e o Nagios analisados, parte-se então para a criação de uma tabela com os

recursos destes softwares, contendo o que a solução proposta também irá possuir.

2.3.3 Tabela comparativa de softwares de gerência de redes

Na Tabela 9, é exibida uma tabela comparativa, mostrando os recursos mais importantes

disponíveis em cada um dos softwares de gerência de redes estudados e os recursos que foram

implementados na solução proposta.

Page 50: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

39

Tabela 9. Tabela comparativa de softwares de gerência de redes

Recurso Nagios Cacti Solução Proposta Exibe o estado de hosts

Sim Não Sim

Exibe o estado de serviços

Sim Não Sim

Construção de gráficos de uso de hosts e serviços

Não Sim Sim

Exibe a topologia da rede

Sim Não Sim

Exibe os hosts distribuídos geograficamente

Não Não Sim

Suporte ao SNMP Sim Sim Sim Suporte ao CMIP Não Não Não Plataforma Web Web Desktop Alerta por Email, ... Não possui Email

Page 51: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

3 PROJETO

Nesta sessão estão descritas as modelagens das duas aplicações propostas: Motor e Interface

do usuário. A modelagem utilizará a UML (Unified Modeling Language – Linguagem de

Modelagem Unificada), pois de acordo com Alhir (1998, tradução nossa), é uma linguagem de

modelagem visual pronta para usar extensível, simples, escalável, independente de linguagem e de

processo de desenvolvimento.

O produto final gerado por este trabalho é formado de um motor de coleta e interpretação

dos dados de estado dos hosts monitorados e por uma interface gráfica que processa e exibe as

informações em um formato adequando para o administrador da rede de computadores. Um

exemplo do funcionamento da solução é exibido pela Figura 27. Dependendo da infra-estrutura da

rede, é possível rodar a interface no mesmo computador que está rodando o motor.

Figura 27. Exemplo de uso.

Já o modelo em camadas é exibido Figura 28.

Page 52: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

41

Figura 28. Modelo em camadas.

Host é qualquer dispositivo de rede gerenciável por SNMP. Ele normalmente executa dentro

de um sistema operacional (ex: Microsoft Windows, GNU/Linux, Cisco IOS) ou ainda em

firmwares 2que implementam o protocolo.

Motor implementa o software de tratamento de eventos propriamente dito. As principais

funções do motor do UNMS são: gravar ocorrências (log), enviar alertas, realizar o polling, além de

diversas outras menos perceptíveis pelos demais elementos.

Já a Interface oferece interação do motor com o ser humano. Nela estão contempladas todas

as rotinas de manipulação do motor, tais como cadastros, eventos, relatórios, gráficos e outros.

3.1 Requisitos Funcionais, Não Funcionais e Regras de Negócio

A descrição dos Requisitos Funcionais, Não Funcionais e as Regras de Negócio são

primordiais para a construção de qualquer software, pois descrevem o que e como será criado.

Motor e interface são descritos separadamente.

2 Software embutido em aparelhos eletrônicos, tais como modems, roteadores e switches, entre outros.

Page 53: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

42

3.1.1 Motor

O motor será a aplicação responsável por coletar as informações dos hosts e serviços da rede

e armazená-las. Os requisitos funcionais identificados estão descritos a seguir:

• RF01: O motor deve coletar as informações disponíveis de um host através do

protocolo SNMP.

• RF02: O motor deve gravar as informações coletadas num banco de dados.

• RF03: O motor deve realizar monitoramento por ICMP Echo/Reply em todos os

hosts cadastrados.

• RF04: O motor deve possuir um mecanismo de auto-detecção de hosts na LAN.

Os requisitos não funcionais identificados estão a seguir. A categorização dos itens está

entre parênteses.

• RNF01: O motor deve ser construído utilizando a linguagem de programação C#.

(implementação)

• RNF02: O motor deve utilizar o SGDB PostgreSQL 8.2. (implementação)

• RNF03: O motor deverá ser construído utilizando a plataforma Mono.

(implementação)

• RNF04: O motor deve ser compatível com as versões 1 e 2 do protocolo SNMP.

(conformidade)

• RNF05: O motor não deverá apresentar interface gráfica. (usabilidade)

• RNF06: O motor será concebido como software livre, licenciado nos termos da

licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008).

As regras de negócio identificadas estão a seguir:

• RN01: Caso não haja configurações avançadas de um dado host, o motor irá

monitorá-lo com o uso ICMP-ECHO / ICMP-REPLY.

Page 54: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

43

• RN02: O motor não trata da configuração de traps nos dispositivos de rede.

3.1.2 Interface com o usuário

A interface com o usuário será a aplicação responsável por exibir os dados coletados na tela

bem como permitir a configuração do sistema. Os requisitos funcionais identificados são os

seguintes:

• RF01: A interface deve permitir o cadastro de hosts.

• RF02: A interface deve permitir o cadastro de serviços que serão monitorados.

• RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o

mecanismo do Google Earth.

• RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e

seu estado.

• RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços

por host com o respectivo estado e descrição.

• RF06: A interface deve permitir o cadastro de usuários.

• RF07: A interface deve exibir a topologia da rede.

• RF08: A interface deve exibir registros de eventos (logs).

• RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens

selecionados de cada host.

• RF10: O sistema deve permitir que o usuário cadastre grupos de hosts.

• RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da rede

o qual se encontra no motor.

• RF12: A interface deve permitir a visualização do histórico de eventos de um host.

Os requisitos não funcionais identificados para a construção do software estão listados

abaixo. As categorias de cada requisito estão entre parênteses.

Page 55: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

44

• RNF01: A interface deve ser desenvolvida utilizando a linguagem de programação

Visual C#. (implementação)

• RNF02: O Sistema de Gerenciamento de Banco de Dados que será utilizado é o

PostgreSQL. (implementação)

• RNF03: A interface será concebida como software livre, licenciado nos termos da

licença GPLv2 (General Public License 2- Licença Pública Geral) (GNU, 2008).

As regras de negócio identificadas são as seguintes:

• RN01: Cada serviço cadastrado deve estar com relacionado com um host

previamente cadastrado.

• RN02: Cada item que está sendo grafado deve estar relacionado com um host

previamente cadastrado.

3.2 Diagramas de Caso de Uso

Os diagramas de caso de uso são importantes no projeto de qualquer sistema, pois de acordo

com Alhir (1998, tradução nossa), eles contêm os atores que representam os usuários do sistema,

incluindo os usuários humanos e outros sistemas, além de representar as funcionalidades ou

serviços providos pelo sistema para o usuário.

3.2.1 Motor

O diagrama de caso de uso construído para o Motor da aplicação é exibido na Figura 29.

Figura 29. Diagrama de casos de uso do Motor.

Page 56: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

45

3.2.2 Interface com o usuário

Já os diagramas de caso de uso para a interface são exibidos na Figura 30.

Figura 30. Diagrama de casos de uso da interface.

A descrição dos casos de uso da interface é feita a seguir.

3.2.2.1 UC01 – Efetuar login

Este caso de é responsável por efetuar o login no sistema.

Relações

• RF06: A interface deve permitir o cadastro de usuários.

Condições

• Pré-condição: Ter um usuário já cadastrado.

• Pós-condição: Um usuário está autenticado no sistema.

Cenários

Faz o login {Principal}

Page 57: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

46

1. Ao abrir o sistema, o usuário informa o seu nome de usuário e a senha (Figura 31).

2. Sistema verifica se o usuário e senha estão corretos.

3. O sistema fecha a tela de login e abre a tela principal.

Usuário e/ou senha inválidos {Exceção}

Se no passo 2 o usuário e/ou senha estiverem errados ou usuário não existe

2.1. O sistema exibe uma tela com a mensagem “Usuário e/ou senha inválidos”

Figura 31. Interface de login.

3.2.2.2 UC02 – Cadastra um host

Este caso de uso trata do cadastramento de hosts no sistema.

Relações

• RF01: A interface deve permitir o cadastro de hosts.

• RF10: O sistema deve permitir que o usuário cadastre grupos de hosts.

Condições

• Pré-condição: Um usuário autenticado no sistema.

• Pré-condição: Um tipo de host deve estar cadastrado.

• Pré-condição: Um grupo de host deve estar cadastrado.

• Pós-condição: Um host está cadastrado.

• Pós-condição: O host cadastrado, se ativo, começa a ser monitorado.

Page 58: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

47

Cenários

Cadastra o host {Principal}

1. O usuário abre a interface de cadastro de hosts (Figura 32).

2. O usuário informa os dados do novo host.

3. O usuário clica em “Salvar”, ou no botão com um ícone de disquete.

Altera um host {Alternativo}

Se no passo 2 o usuário quiser alterar um host:

2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado.

2.2. O usuário altera os dados do host.

2.3. O usuário clica em salvar.

Exlcui um host {Alternativo}

Se no passo 2 o usuário quiser excluir um host:

2.1. O usuário clica no ícone de lupa na parte superior e seleciona o host a ser alterado.

2.2. O usuário clica em Excluir ou no botão com um desenho de X.

2.3. Uma janela é exibida pedindo a confirmação da exclusão.

Page 59: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

48

Figura 32. Interface principal do cadastro de hosts.

Page 60: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

49

Altera a Forma de Monitoramento {Alternativo}

Se no passo 2 o usuário quiser alterar ou configurar um modo de monitoramento diferente:

2.1. O usuário clica no botão “Monitoramento”.

2.2. O usuário altera os dados na interface que irá surgir conforme necessário (Figura

33).

2.3. O usuário clica em OK.

Figura 33. Interface de configuração de monitoramento.

3.2.2.3 UC03 – Cadastra um serviço

Este caso de uso trata do cadastro de serviços que podem ser monitorados.

Relações

• RF02: A interface deve permitir o cadastro de serviços que serão monitorados.

Condições

• Pré-condição: Um host deve estar cadastrado.

• Pós-condição: Um serviço está cadastrado.

Cenários

Page 61: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

50

Cadastra o Serviço {Principal}

1. O usuário abre a interface de cadastro de hosts e clica em Serviços (Figura 34).

2. O usuário preenche os dados sobre o serviço.

3. O usuário clica em “Salvar”.

Altera um serviço {Alternativo}

Se no passo 2 o usuário quiser alterar um serviço:

2.1. O usuário seleciona o serviço na lista.

2.2. O usuário altera os dados do serviço conforme necessário (Figura 34).

2.3. O usuário clica em Salvar.

2.4. Caso as operações na janela foram finalizadas, o usuário clica em OK.

Exclui um serviço {Alternativo}

Se no passo 2 o usuário quiser excluir um serviço:

2.1. O usuário seleciona o serviço na lista.

2.3. O usuário clica em Remover.

2.4. Caso as operações na janela foram finalizadas, o usuário clica em OK.

Page 62: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

51

Figura 34. Interface de cadastro de serviços.

3.2.2.4 UC04 – Cadastra um usuário

Este caso de uso trata do cadastro de um usuário que poderá utilizar o sistema de

monitoramento.

Relações

• RF06: A interface deve permitir o cadastro de usuários.

Condições

• Pré-condição: Um usuário autenticado no sistema.

• Pós-condição: Um novo usuário foi cadastrado, alterado ou excluído no sistema.

Cenários

Cadastra o usuário {Principal}

1. O usuário abre a interface de cadastro de usuários (Figura 35).

2. O usuário informa os dados do novo usuário.

3. O usuário clica em “Salvar”.

Page 63: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

52

Altera um usuário {Alternativo}

Se no passo 2 o usuário quiser alterar os dados de um usuário:

2.1. O usuário faz uma busca clicando no botão com desenho de uma lupa.

2.2. O usuário seleciona o usuário a ser alterado.

2.3. O usuário altera os dados do usuário selecionado.

2.4. O usuário clica em “Salvar”.

Exclui um usuário {Alternativo}

Se no passo 2 o usuário quiser alterar os dados de um usuário:

2.1 O usuário faz uma busca clicando no botão com desenho de uma lupa.

2.2. O usuário seleciona o usuário a ser excluído.

2.3. O usuário clica em “Excluir”.

2.4. Uma janela é exibida pedindo a confirmação da exclusão.

Figura 35. Interface de cadastro de usuários.

3.2.2.5 UC05 – Visualiza o estado dos hosts

Este caso de uso corresponde à visualização dos estados dos hosts cadastrados.

Page 64: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

53

Relações

• RF04: A interface deve exibir uma tela de monitoramento que liste todos os hosts e

seu estado atual.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pré-condição: Um host deve estar cadastrado no sistema.

Cenários

Visualização de Estados de Hosts{Principal}

1. O usuário abre a interface de visualização de estados de hosts (Figura 36).

2. O usuário pode selecionar o Grupo ou tipo de hosts para filtrar quais hosts devem ser

exibidos na lista.

Figura 36. Interface de visualização de estados de hosts.

3.2.2.6 UC06 – Visualiza os estados dos serviços dos hosts

Este caso de uso corresponde à visualização dos estados dos serviços de hosts cadastrados.

Page 65: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

54

Relações

• RF05: A interface deve exibir uma tela de monitoramento que liste todos os serviços

por host com o respectivo estado e descrição.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pré-condição: Um host deve estar cadastrado no sistema.

• Pré-condição: Um serviço deve estar cadastrado.

Cenários

Visualização de Estados de Serviços dos Hosts {Principal}

1. O usuário abre a interface de visualização de estados de hosts (Figura 37).

2. O usuário pode selecionar o Grupo de hosts para filtrar quais serviços dos hosts

devem ser exibidos na lista.

Figura 37. Interface de visualização de estados dos serviços dos hosts.

Page 66: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

55

3.2.2.7 UC07 – Visualiza a topologia lógica da rede

Este caso de uso corresponde à visualização da topologia lógica da rede.

Relações

• RF07: A interface deve exibir a topologia lógica da rede.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pré-condição: Um host deve estar cadastrado no sistema.

Cenários

Visualização da Topologia Lógica da Rede {Principal}

1. O usuário abre a interface de visualização da topologia lógica da rede (Figura 38).

Figura 38. Interface de visualização da topologia da rede.

Page 67: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

56

3.2.2.8 UC08 - Visualiza os hosts geograficamente no Google Earth

Este caso de uso corresponde à visualização dos hosts utilizando o mecanismo do Google

Earth.

Relações

• RF03: A interface deve exibir a localização dos hosts cadastrados utilizando o

mecanismo do Google Earth.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pré-condição: Um host deve estar cadastrado no sistema.

Cenários

Visualização geográfica de hosts {Principal}

1. O usuário abre a interface de visualização do posicionamento geográfico dos hosts (Figura 39).

2. O software Google Earth, se instalado, irá exibir os hosts cadastrados.

Figura 39. Interface para a chamada da visualização de hosts no Google Earth.

Page 68: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

57

3.2.2.9 UC10 – Visualiza gráficos de uso

Este caso de uso corresponde a visualização de gráficos de utilização e/ou carga de recursos

dos hosts.

Relações

• RF09: A interface deve exibir graficamente, o histórico da taxa de uso dos itens

selecionados de cada host.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pré-condição: Um host deve estar cadastrado no sistema.

Cenários

Visualização de gráficos {Principal}

1. O usuário abre a tela de exibição de gráficos (Figura 40).

2. O usuário seleciona qual host, monitor e o período de visualização.

3. O usuário clica no botão Visualizar.

Figura 40. Visualização de gráficos.

Page 69: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

58

3.2.2.10 UC11 – Visualiza registros de eventos

Este caso de uso corresponde a visualização de registros (logs).

Relações

• RF08: A interface deve exibir registros de eventos (logs).

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

Cenários

Visualização de registro de eventos {Principal}

1. O usuário abre a tela de exibição de eventos (Figura 41).

Figura 41. Visualização de eventos.

Page 70: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

59

3.2.2.11 UC12 – Cadastro automático de hosts

Este caso de uso corresponde a auto-detecção de hosts na rede.

Relações

• RF11: A interface deve permitir ao usuário iniciar o recurso de auto-detecção da

rede.

Condições

• Pré-condição: O usuário deve estar autenticado no sistema.

• Pós-condição: Um ou mais hosts foram adicionados no sistema.

Cenários

Detecção de hosts {Principal}

1. O usuário abre a tela de detecção de hosts (Figura 42).

2. O usuário seleciona o método de detecção.

3. O usuário clica em “Iniciar”.

4. Uma barra de progresso indica o andamento da detecção.

5. Ao final do processo, o usuário selecione os hosts a serem adicionados e clica em

salvar.

Page 71: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

60

Figura 42. Detectando hosts.

3.3 Diagramas de Classe

De acordo com Booch, Rumbaugh e Jacobson (2005, tradução nossa), “Os diagramas de

classes são os diagramas encontrados com maior freqüência na modelagem de sistemas orientados a

objetos. Um diagrama de classes mostra um conjunto de classes, interfaces e colaborações e seus

relacionamentos”. As classes, de acordo com Alhir (1998, tradução nossa), são entidades que

possuem atributos, operações e associações. As associações representam o relacionamento entre

duas ou mais classes que possuem em comum, algumas características.

Para o correto entendimento do funcionamento e construção dos módulos, os diagramas de

classes são exibidos nas sessões seguintes.

Page 72: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

61

3.3.1 Motor

A Figura 43 exibe o diagrama de classes do motor.

Figura 43. Diagrama de classes do motor.

A descrição de cada classe é exibida a seguir:

• Host: Esta classe corresponde a um host;

• HostService: Esta classe corresponde a um serviço que se encontra num host;

• ServiceType: Esta classe representa um tipo de serviço;

• DateTimePeriod: É uma classe simples que possui dois atributos que definem um

intervalo de tempo. Ela está ligada à classe Host, pois define quais intervalos de tempo

este não será monitorado;

• HostData: Classe que guarda qualquer tipo de dado relacionado à um host. Normalmente

será preenchida por dados da MIB do host;

• Trap: Classe representa uma trap recebida pelo motor. Esta ligada a um Host pois este

pode possuir várias traps;

• Group: Representa um grupo de hosts;

• User: corresponde à um usuário do sistema;

Page 73: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

62

• StateAlert: classe que contém dados sobre em qual situação pode se emitir um alerta

devido uma trap;

• MonitoringType: é um enumerator que identifica qual é o tipo de monitoramento de um

host; e

• Engine: classe responsável por todas as operações do motor.

3.3.2 Interface

O diagrama de classes da interface é semelhante ao diagrama do motor, sendo que apenas a

classe Engine não está presente.

Page 74: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

63

3.4 Diagrama Entidade-Relacional

O diagrama entidade-relacional, apesar de não ser padrão UML, ele é importante, pois

define a estrutura do banco de dados. O diagrama resultante para este projeto é exibido pela Figura

44.

Figura 44. Diagrama Entidade-Relacional.

Page 75: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

64

4 DESENVOLVIMENTO

A programação do UNMS empregou as seguintes ferramentas:

• Microsoft Visual Studio 2005

• Banco de dados PostgreSQL 8.3

• pgAdmin III

• MonoDevelop 1.0

Ao utilizar o Visual Studio 2005 (VISUALSTUDIO, 2008) com a linguagem de

programação C#, foi utilizada uma biblioteca de conexão com o banco de dados que visa facilitar o

uso do nPgSQL (POSTGRESQL, 2008). A utilização de ODBC foi descartada pelo fato de oferecer

desempenho inferior se comparado com uma conexão direta com o banco de dados.

Foi utilizado o padrão DAO (Data Access Object) de desenvolvimento. Este padrão permite

que ocorra a separação da lógica de negócio da parte que faz o tratamento do acesso aos dados

persistidos (BUSHMANN; HENNEY; SCHMIDT, 2007, tradução nossa).

Com base neste padrão, uma maneira um pouco diferente de desenvolvimento foi adotada.

Para garantir uma boa modularidade, optou-se por desenvolver estes itens da seguinte forma:

1. Um Project que possui as classes entidade (beans) e persistência;

2. Um Project que possui as classes de visão.

A Figura 45 demonstra no Visual Studio como foi abordado o padrão de desenvolvimento DAO. O

Project Hosts apresenta, entre outros, a classe Bean (Host) e a classe DAO (HostDAO).

Page 76: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

65

Figura 45. Formato de desenvolvimento.

Portanto, para cada entidade do sistema, haverá dois Projects em uma Solution do Visual Studio.

Isto garante que implementações e correções futuras sejam facilitadas. Além disso, este formato

permite que tanto o motor quanto a interface utilizem os mesmos Projects de beans e DAO. Além

disso, o HostDAO foi utilizado para acesso a bases SNMP no host.

Antes de aprofundar o desenvolvimento dos recursos mais importantes do motor e da

interface, é necessário entender o processo da criação da Classe de manipulação de dados do

protocolo SNMP.

4.1 Classe de manipulação de dados do protocolo SNMP

Para desenvolver um software que possa se comunicar através de SNMP com os dispositivos

de rede, foi necessário pesquisar bibliotecas que fornecessem os recursos necessários para isto, já

que o .NET Framework não possui tal recurso. Entretanto, com o objetivo de adquirir um

conhecimento mais aprofundado sobre o assunto, foi decidido que uma biblioteca própria fosse

construída, resultando em mais assuntos a serem revisados. O estudo bibliotecas já existentes

ajudaram a compreender melhor o protocolo. A lista de bibliotecas estudadas é exibida pela Tabela

10.

Page 77: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

66

Tabela 10. Bibliotecas SNMP pesquisadas

Biblioteca Descrição An SNMP Library for .NET Framework (CROWE, 2005)

Esta biblioteca é bastante completa, mas complexa. Possui métodos de tradução de OIDs para descrição e vice-versa.

SNMP Library (CODEPROJECT, 2008)

Possui métodos simples de utilização. Por outro lado, necessita de instância de alguns objetos que a torna confusa. Além disso, ela é carente em alguns recursos que são necessários para este projeto.

Para construir uma biblioteca de acessos SNMP, inicialmente foram necessários estudos

sobre o funcionamento de mais baixo nível do protocolo. O entendimento da estrutura do datagrama

SNMP, exibida pela Figura 46, foi primordial para a construção da biblioteca.

Figura 46. Datagrama SNMP.

Fonte: Adaptado de Bruey (2008).

Conforme o estudo e o desenvolvimento ocorriam através de observações no diagrama, o

padrão TLV (Type, Length, Value – Tipo, Tamanho e Valor) e a codificação BER (Basic Encoding

Rules – Regras de Básicas de Codificação) foram descobertos:

4.1.1 Padrão TLV

Um datagrama SNMP tem sua estrutura básica construída utilizando o padrão TLV (Type,

Length, Value – Tipo, Tamanho e Valor) (JAMHOUR, 2008). O pacote é extremamente organizado

através deste padrão, de modo que cada parte e sub-parte são separadas, especificadas e

dimensionadas de acordo com o valor e tipo. A Figura 47 demonstra o campo community de um

datagrama SNMP. Na Figura 46 (Datagrama SNMP), ele seria inserido inteiramente no local

correspondente, seguindo este padrão.

Figura 47. Espaço community do SNMP.

Page 78: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

67

O campo “tipo” é um valor numérico que corresponde a um tipo de dado disponível no

ASN.1 (IBIDEM). A lista de tipos de dados e seu valor numérico são demonstrados na Tabela 11.

Tabela 11. Tipos de dado do protocolo SNMP utilizado no padrão TLV.

Identificador Valor Boolean 0x01 Integer 0x02 UInt32 0x47 BitString 0x03 OctetString 0x04 ObjectIdentifier 0x06 Null 0x05 Sequence 0x30 Counter32 0x41 Counter64 0x46 Gauge 0x42 TimeTicks 0x43 IPAddress 0x40 Opaque 0x44 NetAddress 0x45

Fonte: Adaptado de CodeProject (2008).

O campo “tamanho” é um valor numérico de significa a quantidade de bytes que o campo

“valor” possui.

4.1.2 Codificação/Decodificação BER

A codificação/decodificação BER (Basic Encoding Rules – Regras Básicas de Codificação)

é o sistema adotado para codificação dos dados para transferência do datagrama SNMP pela rede

(JAMHOUR, 2008).

O BER aplicado ao SNMP é utilizado em casos em que certamente algum valor ocupará

mais de um byte. Seu funcionamento consiste em marcar com 1 o bit mais à esquerda de um byte

para indicar que existe mais bytes a serem lidos para a decodificação da mensagem. Caso o bit mais

à esquerda do byte seja 0, quer dizer que este é o último byte a ser lido.

Para exemplificar, um OID deverá ser convertido em um vetor de bytes, para que ele seja

incorporado ao pacote SNMP. O OID utilizado é 1.3.6.1756.3.1. O valor 1756 é o ponto em que

será necessário aplicar a codificação.

Page 79: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

68

Inicialmente, converte-se 1756 para binário: 11011011100 (para facilitar a leitura, em

hexadecimal, o seu valor é 0x6DC). A seguir, é necessário separar o valor de sete em sete bits,

conforme a Figura 48.

1101 1011100

Figura 48. Valor binário de sete em sete bits.

A seguir, os valores separados devem ser completados para todos terem oito bits. Ao serem

completados, são marcados os bits mais a esquerda conforme a regra de codificação BER. O

resultado é exibido na Figura 49. Os valores grifados são os bits de indicação.

10001101 01011100

Figura 49. Resultado da codificação BER.

4.1.3 A biblioteca de classes resultante

As pesquisas realizadas bem como a compreensão dos novos conceitos resultaram na

biblioteca de acesso a dados do protocolo SNMP, batizada de “libSNMP”. Esta possui enumerators,

classes com métodos de codificação/decodificação BER e classe com métodos para manipulação de

dados do SNMP.

A classe de codificação BER possui apenas dois métodos, exibidos pela Figura 50. Ambos

os métodos trabalham com um vetor de bytes (byte[]) e um valor inteiro de 32 bits sem sinal

(UInt32).

Public static byte[] Encode(UInt32 source); Public static UInt32 Decode(byte[] source);

Figura 50. Métodos da classe de codificação/decodificação BER

A principal classe desta biblioteca é a “Snmp”. Esta possui métodos estáticos, responsáveis

por consultar os objetos gerenciáveis de dispositivos de rede e retornar os resultados. Além disto,

existem também outros métodos que auxiliam no desenvolvimento. A Figura 51 exibe a lista de

métodos públicos existentes.

Page 80: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

69

Public static SnmpData Request(SnmpVersion ver, string community, SnmpOp op, string oid, string host); public static SnmpData RequestTextual(SnmpVersion ver, string community, SnmpOp op, string textualDesc, string host); public static SnmpDataList RequestWalk(SnmpVersion ver, string community, string startOid, string host); public static string TranslateToDescr(string oid); public static string TranslateToOid(string textualDescr); public static string GetDeviceDescription(DeviceType dt, int deviceIndex, string host, string community);

Figura 51. Métodos da classe de Snmp.

O método Request é o método responsável por realizar uma operação sobre algum valor

correspondente ao OID informado. O tipo da operação é passada por parâmetro através de um

enumerator. A versão do protocolo também é selecionada por um enumerator.

O método RequestTextual é semelhante ao Request, mas a operação é realizada passando a

descrição textual do OID. Dentro do método ocorre uma operação de tradução da descrição em um

OID, já que em um pacote SNMP não suporta operações utilizando-se a descrição textual.

O RequestWalk utiliza-se de uma operação do SNMP, o get-next. Através disto, é possível

navegar na árvore de OIDs e resgatar vários dados através de um único método. A operação get-

next não possui critério de parada, ou seja, é necessário um controle no próprio método de

requisição. Para isto, utilizou-se um laço infinito que realizaria um break caso o próximo OID não

comece com OID fornecido como parâmetro. Isto foi possível através do método

String.StartsWith().

Os métodos TranslateToDescr e TranslateToOid são os responsáveis pela conversão de um

OID para sua descrição e vice-versa. Esta operação é possível, pois existe uma tabela em memória

que possui os principais OIDs e suas respectivas descrições.

O método GetDeviceDescription é utilizado principalmente para consultar qual o nome de

um dispositivo de rede ou disco, baseado em uma análise simples do OID passado por parâmetro.

O conceito de TLV não exige uma classe ou métodos para seu tratamento. Isto ocorre pelo

fato de que este conceito seja utilizado diretamente na construção e decodificação do pacote SNMP.

Portanto, o TLV está embutido em todos os métodos do tipo Request presentes na libSNMP.

Page 81: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

70

Cada método do Request retorna um tipo SnmpData ou um SnmpDataList. O SnmpDataList

é uma lista de SnmpData que contém métodos de exibição de dados para o console, métodos de

adição diferenciados e de consulta. A definição da classe SnmpData é exibida pela Figura 52 .

public SnmpDataType Type; public object Value; public string Oid; public string Description; public string DescriptionWithIndex; public override string ToString();

Figura 52. Métodos e atributos da classe SnmpData.

Um SnmpDataType é selecionado em um enumerator conforme o pacote de resposta de

algum Request. O atributo Value possui o valor recebido pela resposta e é do tipo object, pois este

tipo pode guardar qualquer tipo de informação, podendo ser um tipo básico como int ou uma String

por exemplo. Description e DecriptionWithIndex retornam uma descrição do dado, de acordo com a

tabela em memória previamente citada. O método ToString() foi construído para que o objeto

SnmpData possa ser exibido de maneira mais clara.

Nesta mesma biblioteca, existe uma classe privada chamada mib2. Esta contém um objeto

DataTable no qual é possível carregar dados em memória e realizar SELECT, como se fosse num

banco de dados que suporte SQL. Neste objeto, existem vários registros que representam os OIDs e

suas descrições textuais. O objetivo desta classe, portanto, é de possibilitar traduções de OIDs para

sua descrição e vice-versa.

4.2 O motor do UNMS

O motor do UNMS é o responsável pela realização de todas as verificações de hosts e

serviços cadastrados. Sua estrutura é composta por dois mecanismos:

• Mecanismo de escalonamento; e

• Mecanismo de verificação de hosts e serviços.

O mecanismo de escalonamento se assemelha ao escalonador de processos de um Sistema

Operacional. No caso do UNMS, o objetivo é verificar quais hosts serão checados na próxima

iteração de verificações do motor. A cada chamada desse mecanismo, o tempo que falta para a

Page 82: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

71

próxima checagem é recalculado levando-se em conta o tempo atual e o tempo da última

verificação. Os hosts selecionados são adicionados na lista de hosts a serem checados.

O mecanismo de verificação de hosts e serviços é acionado pelo método Start(). Sua

primeira ação é escalonar os hosts, verificando quais devem ser checados. No motor, segue-se a

seguinte ordem de verificação:

1. Teste de host através do ICMP Echo/Reply (Ping);

2. Checagem de serviços; e

3. Verificação dos OIDs através de SNMP.

A cada verificação realizada, os dados de cada item verificado são atualizados para visualização

através da interface.

O motor foi todo construído e testado no Visual Studio da Microsoft. Entretanto, devido este

ser construído como aplicação console, sua compatibilidade com o Mono não foi comprometida.

4.2.1 Checando através de ICMP

O protocolo ICMP é outro caso em que o .NET Framework não fornece os métodos

necessários. Para realizar operações com ICMP, foi utilizada a biblioteca Advanced Ping Program

(JAVA2S, 2008).

Esta biblioteca foi de grande utilidade, mas por outro lado foram necessárias

implementações e adaptações. O objetivo foi de padronizar e facilitar o uso da biblioteca. Para as

alterações, o sniffer WireShark (WIRESHARK, 2008) foi bastante utilizado. O resultado final foi

uma classe que possui cinco métodos públicos, exibidos pela Figura 53.

public static List<IPAddress> BroacastICMP(string broadCastIp); public static int Ping(string ipAddress); public static int PingHostName(string hostname); public static List<IPAddress> TraceRoute(string targeIpAddress, int hops); public static List<IPAddress> TraceRouteHostName(string targeHostName, int hops);

Figura 53. Métodos da classe ICMP.

O método BroadcastICMP retorna a lista de IPs que responderam ao ICMP Echo disparado para um

endereço de broadcast. Ping retorna um inteiro com o tempo de resposta de um host em

Page 83: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

72

milissegundos. O PingHostName funciona como o método Ping, mas passando um nome de host.

Os métodos TraceRoute e TraceRouteHostName retornam uma lista de IPs que fazem parte da rota

até o host informado, sendo que o número máximo de passos é informado como parâmetro.

A verificação por ICMP ocorre em todos os hosts escalonados para uma determinada

iteração, independente do seu tipo de monitoramento. Neste caso, os hosts são atualizados quanto

ao resultado obtido pelo ICMP Echo/Reply e em casos de problema, um registro é criado no log.

4.2.2 Checando serviços

Este recurso do motor é o responsável pela verificação de serviços de um determinado host

de uma porta TCP. Para sua checagem, foi elaborado um método que recebe o nome do host e a

porta, retornando um valor em milissegundos correspondente ao tempo de resposta do serviço.

Inicialmente, é armazenado o horário de início da verificação. Então, um Socket TCP é

instanciado com o objetivo de se conectar a porta do host informado. Após a conexão, já ocorre a

desconexão e o cálculo do tempo que a operação levou é retornado. Caso ocorra um erro de

conexão é retornado o valor 9999. O tempo limite para verificação de cada porta é de 1 segundo (ou

1000 milissegundos).

O sistema de registro de eventos para os serviços é igual ao processo de verificação por

ICMP. O tempo de resposta da última medição é armazenado e em casos de erro um registro no log

é adicionado.

4.2.3 Checando os OIDs

Cada OID cadastrado para um host é verificado a cada iteração para qual o host foi

escalonado. Para a checagem, foi utilizado o método Snmp.Request, disponível na biblioteca

construída durante o TCC-2.

Diferente dos outros dois métodos de verificação, o sistema de verificação SNMP armazena

os dados adicionando-os na tabela e não alterando os já existentes. Isto é necessário para a criação

dos gráficos. Por outro lado, segue a mesma regra em que caso algum erro seja encontrado, um

registro é criado na tabela de log.

Page 84: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

73

4.3 Desenvolvimento da Interface

A interface do UNMS é a responsável pela exibição dos dados registrados pelo motor de

uma maneira amigável ao usuário. Em sua construção, foi proposto um sistema multi-plataforma e o

Gtk# seria o sistema de interface gráfica a ser utilizado.

Com o MonoDevelop (MONODEVELOP, 2008), é possível construir aplicações multi-

plataforma para a plataforma .NET com interface gráfica Gtk# e outras. Esta ferramenta é

relativamente nova, e a ausência de recursos como break-points, watches entre outros, se tornou um

fator decisivo. O resultado foi o abandono desta ferramenta durante o desenvolvimento da interface

e o Visual Studio da Microsoft foi utilizado.

Espera-se, que com o avanço do projeto Mono, ferramentas gratuitas como o MonoDevelop

se tornem mais completas. Como o UNMS foi construído de forma modular, seria possível re-

utilizar as DLLs construídas no desenvolvimento de uma interface multi-plataforma.

Todas as telas de cadastro do sistema foram construídas utilizando a herança de formulários.

Este recurso está disponível no Windows Forms e busca o reaproveitamento do código. Isto ocorre

ao construir uma interface básica e seus métodos e então criar um novo Form o qual irá herdar desta

interface. O resultado no sistema são interfaces padronizadas e com uma lista pronta de todos os

métodos a serem implementados. Os componentes do Form “pai” são exibidos na interface de

desenvolvimento em um modo de somente leitura.

Page 85: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

74

4.3.1 Construção de gráficos na plataforma .NET

Para a construção de gráficos em .NET, foi necessário a utilização de uma biblioteca não

pertencente ao .NET Framework. Para este TCC, foi utilizado o .Net Charting

(DOTNETCHARTING, 2008), um componente pago. Apesar disso, ele pode ser utilizado

gratuitamente. Sem o licenciamento, ele exibe um logotipo no gráfico, conforme a Figura 54.

Figura 54. Exemplo de uso para o .Net Charting e seu logotipo.

.Net Charting é integrado com o Microsoft Visual Studio através de sua adição na lista de

componentes, conforme a Figura 55.

Figura 55. .Net Charting no Visual Studio.

O componente é utilizado ao arrastá-lo ao formulário Windows. Seu posicionamento e

dimensões são ajustados, e então se codifica o gráfico. É possível também, utilizá-lo na construção

Page 86: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

75

de páginas em ASP.NET. No Windows, as escalas são ajustadas conforme as dimensões do

formulário sem necessidade da criação de código adicional.

A seguir, na Figura 56, é exibido um exemplo de gráfico de barras construído com o .Net

Charting.

Figura 56. .Net Charting e gráfico de barras.

No UNMS, os gráficos são de linha. A Figura 57 apresenta um trecho de codificação

comentado, exemplificando o uso do .Net Charting.

chart1.Series = new Series(); //Inicia nova série chart1.Type = ChartType.Scatter; //O gráfico é de linha chart1.SeriesCollection.Clear(); //A coleção de Series é apagada chart1.Title = String.Empty; //O título do gráfico é branco chart1.TitleBox = new Box(); //Re-inicia a caixa do título do gráfico chart1.XAxis.Scale = dotnetCHARTING.WinForms.Scale.Time; //A escala do eixo X é por tempo chart1.XAxis.TimeInterval = TimeInterval.Minute; //A escala é em minutos chart1.XAxis.FormatString = "HH:mm"; //O formato de exibição de dados do eixo X é Horas:Minutos chart1.XAxis.Name = "Tempo"; //O título para o eixo X é tempo chart1.YAxis.Name = "% Carga"; //O título do eixo Y é % Carga //Inserindo valores no gráfico Element el; //Declaro um elemento no gráfico //Laço de repetição que possui um objetos que contêm uma data e um Double foreach (KeyValuePair<DateTime, Double> kvp in ls) { el = new Element(); //Instância de um novo elemento el.YValue = kvp.Value; el.XDateTime = kvp.Key; chart1.Series.AddElements(el); //Insere o novo elemento no gráfico } chart1.SeriesCollection.Add(); //Insere a coleção de dados no gráfico chart1.SeriesCollection[0].DefaultElement.Color = Color.Green; //A linha do gráfico é verde //Não é desejado que cada valor possua um marcador individual chart1.SeriesCollection[0].DefaultElement.Marker.Visible = false;

Figura 57. Exemplo de uso do .Net Charting.

Page 87: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

76

4.3.2 Exibindo hosts no Google Earth

A tarefa de se criar um mecanismo que exibe os hosts no Google Earth foi bastante

desafiadora. Após várias pesquisas, foi encontrado um método, o qual consiste na criação de

arquivos KML (Keyhole Markup Language – Linguagem de Marcação Keyhole).

O arquivo KML é um XML que possui as informações necessárias para se desenhar marcos

em um software como o Google Earth. Sua estrutura é facilmente descoberta ao criar um marco no

próprio Google Earth e depois utilizar a opção “Salvar meus lugares”.

Com o KML gerado pelo Google Earth em mãos, o passo seguinte foi codificar uma classe

que possui métodos que criam um KML a partir de dados geográficos. A biblioteca resultante

possui duas classes: Location (Localização) e KmlGen (Gerador do KML).

A classe Location possui apenas três atributos que identificam um local: nome, latitude e

longitude.

A classe KmlGen possui uma lista de Location. Com a lista contendo as localizações, pode-

se acionar o método CreateKml, fornecendo o caminho onde será criado o Kml.

Para efeitos de teste, um arquivo KML foi gerado a partir do software Google Earth. Sua

extensão foi alterada para XML e o arquivo foi aberto para exibição no Internet Explorer. Por parte

do KmlGen, foi adotado o mesmo procedimento. Então, com os dois XML sendo exibidos lado a

lado foi possível constatar as diferenças e então corrigi-las. O arquivo que demonstra o KML

gerado pela ferramenta é exibido Figura 58. Vale ressaltar o grau de precisão da latitude e

longitude.

Page 88: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

77

<?xml version="1.0" encoding="UTF-8" ?> - <kml xmlns="http://earth.google.com/kml/2.2"> - <Document> <name>Casa.kml</name> - <Style id="sn_ylw-pushpin"> - <IconStyle> <scale>1.1</scale> - <Icon> <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href> </Icon> <hotSpot x="20" y="2" xunits="pixels" yunits="pixels" /> </IconStyle> </Style> - <Style id="sh_ylw-pushpin"> - <IconStyle> <scale>1.3</scale> - <Icon> <href>http://maps.google.com/mapfiles/kml/pushpin/ylw-pushpin.png</href> </Icon> <hotSpot x="20" y="2" xunits="pixels" yunits="pixels" /> </IconStyle> </Style> - <StyleMap id="msn_ylw-pushpin"> - <Pair> <key>normal</key> <styleUrl>#sn_ylw-pushpin</styleUrl> </Pair> - <Pair> <key>highlight</key> <styleUrl>#sh_ylw-pushpin</styleUrl> </Pair> </StyleMap> - <Placemark> <name>Casa</name> - <LookAt> <longitude>-48.91114504933488</longitude> <latitude>-27.09442286390817</latitude> <altitude>0</altitude> <range>158.9999911670838</range> <tilt>0</tilt> <heading>0.1669381198608628</heading> <altitudeMode>relativeToGround</altitudeMode> </LookAt> <styleUrl>#msn_ylw-pushpin</styleUrl> - <Point> <coordinates>-48.91131727570033,-27.09449447216344,0</coordinates> </Point> </Placemark> </Document> </kml>

Figura 58. Exemplo de KML.

O Google Earth exibe os hosts através dos marcadores amarelos, que é o modo descrito pelo

KML gerado. A maneira de como o software exibe os hosts é exibida pela Figura 59.

Page 89: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

78

Figura 59. Google Earth exibindo os hosts.

Com a biblioteca concluída, foi adicionado ao menu a opção de exibição dos hosts no

Google Earth. Esta opção gera o Kml e inicia o Google Earth o passando como parâmetro.

4.3.3 Desenvolvimento da auto-descoberta de dispositivos

A auto-descoberta tem como objetivo de detectar todos os hosts presentes na mesma sub-

rede de onde a interface está sendo executada. Através do protocolo ICMP, o qual utiliza a mesma

biblioteca descrita em “Checando através de ICMP”, o mecanismo de detecção pode funcionar de

duas maneiras conforme o desejo do usuário:

• Descoberta por broadcast; e

• Teste de IP por IP.

O sistema de descoberta por broadcast consiste em disparar o ICMP Echo (Ping) para o

endereço de broadcast da sub-rede. Desta forma, todos os hosts presentes irão responder com um

Reply e seus IPs serão armazenados em uma lista.

O modo de teste de IP por IP funciona através de um laço de repetição que dispara o ICMP

Echo individualmente para cada IP que está na sub-rede. Todos os hosts que responderem a

requisição serão armazenados em uma lista.

Com a lista de hosts presentes na lista, é possível selecionar quais os hosts que se deseja

adicionar ao UNMS. Hosts já cadastrados não são exibidos nesta tela evitando duplicidade.

Page 90: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

79

4.4 Testes do UNMS

Foram realizados experimentos durante todo o processo de desenvolvimento do UNMS. Os

testes foram realizados no Laboratório de Redes da UNIVALI. Estes testes foram feitos à medida

que o aplicativo foi se tornando cada vez mais complexo. Além disso, testes de funcionamento

gerais foram executados.

4.4.1 Processo de testes da biblioteca de acesso SNMP

Devido à alta complexidade no processo de codificação de biblioteca de classes SNMP, uma

plataforma de testes foi montada de forma a facilitar a construção desta biblioteca. Os testes foram

realizados no Laboratório de Redes da UNIVALI, utilizando a infra-estrutura presente além dos

softwares VMWare (VMWARE, 2008) e Wireshark.

No VMWare, foi instalado uma máquina virtual com o Sistema Operacional Linux e

distribuição Ubuntu 7.04 (UBUNTU, 2008). Com o sistema operacional Windows rodando de

forma nativa no computador, comparava-se o funcionamento dos utilitários presentes no Linux

como snmpwalk e snmpget com os métodos presentes na biblioteca, até então em desenvolvimento.

Com a utilização do Wireshark, foi possível perceber os erros cometidos no processo. A Figura 60,

exibe o caso em que o sniffer detectou erros na construção do datagrama SNMP pela biblioteca e

exibe também um datagrama construído corretamente, construído pelo utilitário snmpget.

Figura 60. Wireshark detectando os datagramas SNMP.

É possível observar na Figura 60 os pacotes 3 e 4, sendo respectivamente, a requisição e uma

resposta, ambos corretos. No pacote 17, observa-se uma requisição inválida, esta realizada pela

biblioteca.

Para que esta biblioteca funcione corretamente, algumas classe auxiliares também foram

testadas. A classe de codificação/decodificação BER sofreu uma série de testes. Vários valores

maiores que 255 foram processados por esta classe de modo a detectar possíveis erros.

Page 91: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

80

No próprio Wireshark, foi possível observar problemas através da análise do hexadecimal

correspondente ao pacote capturado. Tal comparação foi feita colando-se o hexadecimal dos

datagramas correto e incorreto no bloco de notas, conforme a Figura 61.

Figura 61. Comparando o datagrama correto (linha superior) e o incorreto (linha inferior).

Vale destacar que o hexadecimal desnecessário já é descartado, selecionando a parte que trata de

SNMP no próprio Wireshark. Dados aleatórios como o identificador da requisição SNMP, que é

identificável analisando o datagrama também foram desconsiderados. Na Figura 61, a linha superior

representa parte do datagrama correto e a inferior o incorreto. Ao observar as diferenças existentes,

as devidas correções foram realizadas.

4.4.2 Testes da ferramenta

Com as bibliotecas necessárias já concluídas, e o desenvolvimento do aplicativo em

andamento, os testes foram iniciados. Entretanto, destacam-se os dois principais testes realizados no

Laboratório de Redes da UNIVALI.

O primeiro teste foi realizado quando a interface era uma mera ferramenta de validação dos

dados coletados pelo motor. Neste caso, foi possível observar alguns pequenos erros de coleta e que

o motor não atualizava a lista de hosts de forma adequada. Neste cenário, foram elaboradas

modificações no escalonador de hosts de modo que este coletasse os novos hosts automaticamente a

cada iteração. Deste modo, tanto a interface quanto o motor estariam trabalhando com dados

atualizados. Neste mesmo teste, foi verificado como seria o funcionamento do motor no Linux,

executando através da plataforma Mono. Como esperado, não houve problemas.

Neste mesmo teste, buscou-se avaliar o mecanismo responsável por exibir os OIDs que

podem ser utilizados para construir gráficos. Possíveis erros podiam ocorrer na coleta em hosts que

executavam sistemas operacionais diferentes do Windows, devido a possíveis vícios no

desenvolvimento para este sistema operacional. Entretanto, tais erros não apareceram o que

comprovou mais uma vez o bom funcionamento da biblioteca construída bem como a grande

utilidade do protocolo SNMP e a MIB-II.

Page 92: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

81

O segundo teste foi realizado para verificar possíveis erros. Este teste foi realizado também

no Laboratório de Redes da UNIVALI no qual a ferramenta rodou durante uma hora e meia. Neste

cenário, nenhum host ou serviço foi alterado ou adicionado, sendo o principal foco o motor do

aplicativo. Com monitoramentos realizados periodicamente no gerenciador de tarefas do Windows,

foram observadas as porcentagens de consumo de processador, memória e do adaptador de rede. A

Tabela 12 exibe de forma resumida os resultados deste segundo teste.

Tabela 12. Dados sobre o segundo teste

Dado Valor Porcentagem de uso do processador pelo processo motor

4% (valor máximo)

Memória utilizada pelo processo Mínimo: 11 Mb Máximo: 40 Mb

Porcentagem de uso da rede Mínimo: 0,02% Máximo: 03%

Hosts monitorados por ICMP 17 Hosts monitorados por SNMP 03 Serviços monitorados 10 Período de polling 30 segundos para todos os hosts

Neste mesmo teste, foram executados os testes de detecção de hosts. Na infra-estrutura de

redes em que se encontra o Laboratório de Redes da UNIVALI, a máscara de rede utilizada é a

255.255.254.0, o que permite a presença de 510 IPs para hosts, 1 IP identificador da rede e 1 IP de

broadcast. Com o teste desta funcionalidade sendo realizado após as 20h, foram detectados 458

hosts através da detecção IP por IP. O processo de detecção por broadcast, de forma estranha,

acabou não detectando host algum. Entretanto, verificou-se no Wireshark que IPs de classe A

(10.0.0.0) estavam respondendo ao pedido sendo que IPs de classe C (200.169.60.0) eram

esperados. Estes IPs foram descartados.

Além disso, buscou-se detectar possíveis erros durante a coleta de dados SNMP para

construção de gráficos. Esperava-se que possíveis erros pudessem surgir quando a coleta ocorresse

em hosts que executassem em Linux, semelhante ao caso já descrito. Felizmente, estes erros não

apareceram e o gráfico de carga de processador de um host com Linux foi construído com sucesso,

conforme demonstrado na Figura 62.

Page 93: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

82

Figura 62. O gráfico construído corretamente para medir a carga de processamento de um host.

Para validar o mecanismo de criação de gráficos, o motor foi iniciado com o host Linux sem

processamento algum. Após um pequeno período, foi iniciado o aplicativo “top” o qual comprovou

que o computador estava com baixa porcentagem de processamento. Para simular um

processamento maior, o aplicativo top foi reiniciado, mas com uma taxa de atualização de dados em

0,01 (a linha de comando utilizada foi: top –d 0.01), o que fez com que o uso do processador pelo

próprio aplicativo aumentasse para cerca de 10%.

Page 94: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

83

5 CONCLUSÕES

Este trabalho de conclusão de curso demonstrou o processo de construção de um software de

monitoramento de redes, o UNMS. A utilização em conjunto de vários conceitos, arquiteturas e

componentes resultou em um aplicativo potencialmente útil para os gerentes de redes de

computadores.

A engenharia de software para o UNMS permitiu estudar as diversas facetas necessárias

para a concepção do produto final. A discussão do formato final das interfaces, dos elementos que

são realmente necessários e úteis foi bastante discutida durante a banca de TCC-I. Vários

comentários de visitantes e dos avaliadores agregaram recursos adicionais valiosos, como o sistema

de auto-detecção de hosts na rede. Vários itens foram discutidos novamente com o orientador e

puderam ser melhorados.

Durante o processo de criação do software, foram encontradas várias dificuldades em se

desenvolver um software na plataforma Mono. A principal dificuldade foi em utilizar o

MonoDevelop, a principal IDE do Mono. Vários recursos valiosos ao desenvolvedor estão ausentes

nesta ferramenta o que inviabilizou o desenvolvimento nesta plataforma.

Ao descartar a utilização do Mono, utilizou-se o Visual Studio 2005 da Microsoft. Neste

cenário, optou-se por manter o motor do UNMS multi-plataforma, obedecendo às regras de

desenvolvimento necessárias para atingir este objetivo. Por outro lado, interface gráfica do UNMS

não atendeu a esta questão, pois alguns componentes visuais importantes, presentes no Windows

Forms, não existem para o Gtk#.

Ainda sobre a interface gráfica do UNMS, vale destacar o uso de KML para exibição de

pontos geográficos no Google Earth. Tal recurso demonstra grande flexibilidade podendo ser

utilizado para várias finalidades.

Para realizar o desenvolvimento do motor, foi necessário o estudo mais aprofundado sobre o

protocolo SNMP. O conhecimento em Sockets adquirido com o decorrer do curso finalmente foi

colocado em prática pelo autor deste TCC. A construção de uma biblioteca própria para tratamento

da comunicação SNMP demonstrou ser a parte mais prazerosa e desafiante de todo o processo de

construção do UNMS. Além disso, ressalta-se a importância de um software sniffer como o

Page 95: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

84

Wireshark, essencial na criação de um software que utiliza Sockets. Nesta etapa vale destacar que

existe uma grande escassez de material sobre SNMP destinado aos desenvolvedores de software.

O recurso de recebimento de traps, que seria desenvolvido segundo o projeto inicial, acabou

não sendo realizado. Entretanto acredita-se que tal operação seja pouco necessária, pois o UNMS

realiza um monitoramento ativo através do polling que oferece recursos aparentemente similares em

seu modo final de operação.

A gerência de redes é uma área com ampla quantidade de elementos que podem ser

monitorados, implementados e sugeridos. Durante conversas com o orientador e visitantes do TCC-

I, pode-se correlacionar vários aspectos que poderiam ser abordados em trabalhos futuros: 1)

compatibilidade com MIBs específicas; 2) coleta de dados do syslog; 3) implementação em outros

idiomas; 4) interface mais detalhada; 5) estudos sobre escalabilidade; 6) sistema detalhado para

inventário da informática e 6) incrementos no sistema de localização geográfica.

Page 96: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

REFERÊNCIAS BIBLIOGRÁFICAS

ALHIR, Siman Si. UML in a nutshell. Sebastopol: O’Reilly, 1998.

BOOCH, G., RUMBAUGH, J., JACOBSON, I. The unified modeling language user guide. 2.ed. Boston: Addison-Wesley, 2005.

BORNSTEIN, Niel. M.; DUMBILL Edd. Mono: a developer’s notebook. EUA: O’Reilly, 2004.

BRUEY, Douglas. SNMP: Simple? Network Management Protocol. Disponível em: <http://www.rane.com/note161.html>. Acesso em: 25 ago 2008.

BURGESS, Chris. The nagios book. Disponível em: <http://www.nagiosbook.org>. Acesso em: 13 maio 2008.

BUSHMANN, F.; HENNEY, K.; SCHMIDT, D.C. Pattern-oriented software architecture: on patterns and patterns languages. Indianapolis: Willey Publishing, 2007. 5v.

CACTI. CACTI: the complete RRDTool-based Graphing Solution. Disponível em: <http://www.cacti.net>. Acesso em: 14 maio 2008.

DOTNETCHARTING. ASP.NET chart and charting for .NET. Disponível em: <http://www.dotnetcharting.com>. Acesso em: 20 out 2008.

GNU. The GNU General Public License. Disponível em: <http://www.gnu.org/licenses/gpl.html/>. Acesso em: 29 maio 2008.

KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet. 3. ed. São Paulo: Pearson Addison Wesley, 2006.

JAVA2S. Advanced ping program. Disponível em: <http://www.java2s.com/Code/CSharp/Network/AdvancedPingProgram.htm>. Acesso em: 15 out 2008.

JAMHOUR, Edgard. Gerência de Redes (SNMP). Disponível em: <http://www.ppgia.pucpr.br/~jamhour/Pessoal/Mestrado/TARC/LDAP.ppt>. Acesso em: 10 set 2008.

MAURO, Douglas; SCHMIDT, Kevin. Essential SNMP. EUA: O'Reilly, 2001.

MILLER, Mark A. Managing internetworks with SNMP. 2. ed. EUA: M & T Books, 1997.

MONO. Main page - mono. Disponível em: <http://www.mono-project.com>. Acesso em: 23 maio 2008.

MONODEVELOP. Main Page – MonoDevelop. Disponível em: <http://www.monodevelop.com>. Acesso em: 12 set 2008.

NAGIOS. Nagios: home. Disponível em: <http://www.nagios.org>. Acesso em: 13 maio 2008.

Page 97: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

86

NETWORKDICTIONARY. FCAPS: network management functional model. 2008a. Disponível em: <http://www.networkdictionary.com/networking/FCAPS.php>. Acesso em: 01 abr. 2008.

NETWORKDICTIONARY. ISO CMIP: common management information protocol. 2008b. Disponível em: <http://www.networkdictionary.com/protocols/cmip.php>. Acesso em: 01 abr. 2008.

OETIKER, Tobias. RRDTool: about RRDtool. Disponível em: <http://oss.oetiker.ch/rrdtool/>. Acesso em: 14 maio 2008.

RFC 1157. Simple Network Management Protocol (SNMP). 1990. Disponível em: <http://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 01 abr 2008.

RFC 1157. Simple Network Management Protocol (SNMP). 1990. Disponível em: <http://www.ietf.org/rfc/rfc1157.txt>. Acesso em: 01 abr 2008.

RFC 1212. Management Information Base for Network Management of TCP/IP-based internets:MIB-II. 1991. Disponível em: <http://www.ietf.org/rfc/rfc1213.txt>. Acesso em: 01 abr 2008.

RFC 1213. Management Information Base for Network Management of TCP/IP-based internets:MIB-II. 1991. Disponível em: <http://www.ietf.org/rfc/rfc1213.txt>. Acesso em: 01 abr 2008.

RFC 1905. Protocol operations for version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1905.txt>. Acesso em: 01 abr 2008.

RFC 1906. Transport mappings for version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1906.txt>. Acesso em: 01 abr 2008.

RFC 1907. Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996. Disponível em: <http://www.ietf.org/rfc/rfc1907.txt>. Acesso em: 01 abr 2008.

RFC 2571. An architecture for describing SNMP management frameworks. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2571.txt>. Acesso em: 01 abr 2008.

RFC 2572. Message processing and dispatching for the Simple Network Management Protocol (SNMP). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2572.txt>. Acesso em: 01 abr 2008.

RFC 2573. SNMP Applications. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2573.txt>. Acesso em: 01 abr 2008.

RFC 2574. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2574.txt>. Acesso em: 01 abr 2008.

RFC 2575. View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). 1999. Disponível em: <http://www.ietf.org/rfc/rfc2575.txt>. Acesso em: 01 abr 2008.

Page 98: Área de Redes de Computadores por Axel Krieger …siaibib01.univali.br/pdf/Axel Krieger Neto.pdfsoftwares de gerência de redes e que despertou a curiosidade sobre o assunto. •

87

RFC 2579. Textual conventions for SMIv2. 1999. Disponível em: <http://www.ietf.org/rfc/rfc2579.txt>. Acesso em: 01 abr 2008.

SCHÖNIG, Hans-Jücrgen; GESCHWINDE, Ewald. Mono kick start. EUA: Sams Publishing, 2003.

TANENBAUM, Andrew S. Redes de computadores. 4. ed. Rio de Janeiro: Campus, 2001.

TAROUCO et al. Gerenciamento de redes: uma abordagem de Sistemas Abertos. Itaim-Bibi: Makron Books, 1993.

TEMPLEMAN, Julian; VITTER, David. Visual Studio .NET – the .NET Framework black book. EUA: The Coriolis Group, 2002.

TURTSCHI, Adrian; WERRY, Jason; HACK Greg. C# .NET guia do desenvolvedor. 2 ed. Rio de Janeiro: Alta Books, 2004.

UBUNTU. Ubuntu Home Page | Ubuntu. Disponível em: <http://www.ubuntu.com>. Acesso em: 01 ago 2008.

VISUAL STUDIO. Sistema de desenvolvimento Visual Studio. Disponível em: <http://msdn.microsoft.com/pt-br/vstudio/products/default.aspx>. Acesso em: 01 nov 2008.

VMWARE. VMware: Virtualization via Hypervisor, Virtual Machine and Server Consolidation – Vmware. Disponível em: <http://www.vmware.com>. Acesso em 01 ago 2008.

WIRESHARK. Wireshark: Go-deep. Disponível em: <http://www.wireshark.org>. Acesso em: 10 ago 2008.