UNIVERSIDADE REGIONAL DE BLUMENAU

CENTRO DE CIÊNCIAS EXATAS E NATURAIS

CURSO DE ENGENHARIA DE TELECOMUNICAÇÕES

FERRAMENTA PARA GERENCIAMENTO DE FALHAS EM

REDE ETHERNET BASEADA EM PROTOCOLO SNMP

RODRIGO STANGE

BLUMENAU 2008

RODRIGO STANGE

FERRAMENTA PARA GERENCIAMENTO DE FALHAS EM

REDE ETHERNET BASEADA EM PROTOCOLO SNMP

Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso do curso de Engenharia de Telecomunicações.

Prof. Francisco Adell Péricas, Mestre - Orientador

BLUMENAU 2008

FERRAMENTA PARA GERENCIAMENTO DE FALHAS EM

REDE ETHERNET BASEADA EM PROTOCOLO SNMP

Por

RODRIGO STANGE

Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso, pela banca examinadora formada por:

______________________________________________________ Presidente: Prof. Francisco Adell Péricas, Mestre – Orientador, FURB

______________________________________________________ Membro: Prof. José Gil Fausto Zipf, Mestre – FURB

______________________________________________________ Membro: Prof. Sérgio Vidal Garcia Oliveira, Doutor – FURB

Blumenau, 10 de Abril de 2008

Dedico este trabalho aos meus pais pelo apoio, amor e dedicação que sempre me forneceram. À minha irmã que sempre esteve presente em minha vida, mesmo quando distante. Ao carinho, paciência e amor de minha namorada.

AGRADECIMENTOS

A Deus em primeiro lugar por todos acontecimentos e por cada obstáculo que

atravessei, que me fortaleceram e me tornaram uma pessoa melhor.

Aos meus pais por toda a dedicação em minha criação e ensinamentos, pelo amor e

carinho que nunca me faltaram e principalmente pelo caráter que me ensinaram a ter.

Ao professor Francisco Adell Péricas pela forma como conduziu seu encargo de

orientador, mesmo estando distante, forneceu a força inicial para conclusão de mais esta etapa

de minha vida.

Ao amigo Márcio Ernani Kessler por todo o apoio e auxílio que me forneceu na área

da programação.

A todos os meus amigos, os quais seria difícil citar ou chato esquecer alguém.

E finalmente a minha namorada, Elizabeth Peschke, que sempre me deu forças, apoio e

amor nas horas em que mais precisei.

“Viva como se fosse morrer amanhã e aprenda como se fosse viver para sempre.”

Mohandas Karamchand Gandhi

RESUMO

Este trabalho apresenta os principais aspectos do gerenciamento de redes Ethernet e o desenvolvimento de um software para monitoração de equipamentos ativos de rede. O software a ser desenvolvido é capaz de monitorar, obter informações relevantes ao gerente de rede (nome, versão de firmware, tempo de funcionamento, localização), avaliar o estado das interfaces e coletar alertas dos equipamentos gerenciados por ele. A ferramenta desenvolvida utiliza o protocolo SNMP para comunicação e gerenciamento dos equipamentos.

Palavras-chave: redes Ethernet, LAN, TCP/IP, SNMP, AutoIT, MIB.

ABSTRACT

This work presents the most important aspects of the management of Ethernet networks and the development of a monitoring software for network equipments. The present software is able to monitoring, information obtaining (hostname, firmware version, uptime, localization), verify the status of interfaces and collect alerts of all equipment managed by it. The tool uses the SNMP protocol for communication and equipment management.

Key-Words: Ethernet networks, LAN, TCP/IP, SNMP, AutoIT, MIB.

LISTA DE ILUSTRAÇÕES

Figura 1: Arquitetura dos sistemas de gerência. ....................................................................... 20

Figura 2 – Protocolo de gerenciamento SNMP. ....................................................................... 23

Figura 3 – SMI: MIB padrão SNMP. ....................................................................................... 27

Quadro 1 – Objetos da MIB-2. ................................................................................................. 29

Figura 4 – Protocolo SNMP sobre a camada de transporte. ..................................................... 32

Figura 5 – Formato das mensagens SNMP. ............................................................................. 33

Figura 6 – Exemplo de aquisição de valores pelo SNMPWALK. ........................................... 36

Figura 7 – Fluxograma do Módulo Principal. .......................................................................... 37

Figura 8 – Fluxograma da função Incluir. ................................................................................ 38

Figura 9 – Fluxograma da função Excluir. ............................................................................... 38

Figura 10 – Fluxograma da função Status. ............................................................................... 39

Figura 11 – Fluxograma da função Informações. ..................................................................... 39

Figura 12 – Fluxograma da função Syslog. .............................................................................. 40

Figura 13 – Fluxograma da função Interfaces. ......................................................................... 40

Figura 14 – Fluxograma da função Incluir da função Interfaces. ............................................. 41

Figura 15 – Fluxograma da função Status de Interfaces. ......................................................... 41

Figura 16 – Fluxograma da função Configurações. ................................................................. 42

Figura 17 – Módulo principal do software. .............................................................................. 43

Figura 18 – Interfaces para inclusão de equipamentos. ............................................................ 44

Figura 19 – Interface de informações. ...................................................................................... 45

Figura 20 – Módulo de seleção de interfaces. .......................................................................... 46

Figura 21 – Módulo de monitoramento de interfaces............................................................... 47

Figura 22 – Módulo de Syslog. ................................................................................................ 47

Figura 23 – Interface completa do protótipo. ........................................................................... 48

LISTA DE SIGLAS

ASN.1 - Abstract Syntax Notation One

CMIP - Common Management Information Protocol

FCAPS - Fault, Configuration, Accounting, Performance, Security

FDDI - Fiber Distributed Data Interface

IP - Internet Protocol

ISO - International Organization for Standartization

LAN - Local Area Network

MAN - Metropolitan Area Network

Mbps - Megabits por segundo

MIB - Management Information Base

OSI - Open System Interconnection

RMON - Remote Monitoring

SNMP - Simple Network Management Protocol

TCP - Transmission Control Protocol

WAN - Wide Area Network

SUMÁRIO

1 INTRODUÇÃO .................................................................................................................. 11

1.1 JUSTIFICATIVA .............................................................................................................. 12

1.2 DEFINIÇÃO DO PROBLEMA ........................................................................................ 12

1.3 QUESTÕES DE PESQUISA ............................................................................................ 13

1.4 OBJETIVOS DO TRABALHO ........................................................................................ 13

1.4.1 Objetivo geral .................................................................................................................. 13

1.4.2 Objetivos específicos ...................................................................................................... 13

1.5 ESTRUTURA DO TRABALHO ...................................................................................... 14

2 REDES ETHERNET ......................................................................................................... 15

2.1 GERENCIAMENTO DE REDES ..................................................................................... 17

2.2 MODELO DE GERENCIAMENTO ................................................................................ 19

2.3 ARQUITETURA SNMP ................................................................................................... 22

2.3.1 PONTOS POSITIVOS E NEGATIVOS DO SNMP ...................................................... 24

2.3.2 EXTENSÕES AO SNMP ............................................................................................... 25

2.3.3 MANAGEMENT INFORMATION BASE .................................................................... 26

2.3.4 FUNCIONAMENTO DO SNMP ................................................................................... 31

3 DESENVOLVIMENTO DO APLICATIVO ..................... ............................................. 34

3.1 REQUISITOS .................................................................................................................... 34

3.2 ESPECIFICAÇÃO ............................................................................................................ 36

3.3 IMPLEMENTAÇÃO ........................................................................................................ 43

4 CONCLUSÃO .................................................................................................................... 49

4.1 EXTENSÕES .................................................................................................................... 50

REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 51

ANEXO .................................................................................................................................... 53

11

1 INTRODUÇÃO

Atualmente é visível o desenvolvimento dos meios de comunicação, buscando sempre

melhores resultados e tecnologias. Este processo exige dos canais de comunicação a utilização

máxima de sua capacidade, sempre com novos serviços e aplicabilidades em áreas nunca

imaginadas. Com o surgimento da Internet, rede mundial de computadores, conseguiu-se

níveis de comunicações imensuráveis, com recursos e meios que tornam o cotidiano mais

simples e eficiente. A partir dessas tecnologias empregadas nas redes atuais surgem também

os problemas de transmissão.

O antigo conceito de “central de computadores” descrito como uma sala para onde os

usuários encaminhavam seus programas a fim de obter o processamento dos mesmos, ficou

ultrapassado. Este conceito foi substituído pelas redes de computadores, onde recursos podem

ser compartilhados facilmente. Empregadas em quase todos os locais, as redes de

computadores devem prover o acesso a informações e serviços de maneira eficaz e sem falhas

de comunicação. Por este motivo, o monitoramento e correção de falhas em redes ethernet

tornam-se tão importantes. É a partir deles que se pode solucionar problemas atuais e evitar

futuras deficiências nos sistemas.

As falhas que podem ocorrer num equipamento de rede, seja em um pequeno

escritório ou numa empresa de grande porte, devem ser identificadas o mais rápido possível a

fim de evitar grandes prejuízos. Para isso torna-se indispensável o uso de softwares que sejam

capazes de monitorar o estado dos equipamentos que compõe a rede. Esses softwares, como

HP OpenView e CiscoWorks, utilizam principalmente o protocolo SNMP (Simple Network

Management Protocol) para obter as informações dos seus objetos monitorados, os quais

estão modelados em bases de informações chamadas MIBs (Management Information Base).

12

1.1 JUSTIFICATIVA

Apesar do constante desenvolvimento de novas tecnologias de transmissão de dados,

todas elas dependem do correto funcionamento para justificar sua instalação. Uma rede de

dados que esteja utilizando como meio de transmissão cabos de categorias diversas, sistemas

ópticos ou mesmo sem fio não é uma rede confiável se não for corretamente monitorada e

gerenciada. Através do monitoramento das redes ethernet pode-se oferecer confiabilidade

para os serviços que trafegam por ela.

Monitorar uma rede significa acompanhar seu funcionamento identificando falhas,

buscando suas origens e evitando que as mesmas possam vir a se repetir no futuro. Significa

também a garantia de funcionamento de sistemas que dependam do meio de transmissão.

Todas essas necessidades citadas justificam a necessidade da criação de programas de

gerência capazes de auxiliar no cotidiano dos administradores de redes.

1.2 DEFINIÇÃO DO PROBLEMA

Uma rede, desde a parte física até a lógica, pode apresentar falhas que comprometerão

seu funcionamento. Para minimizar os impactos dessas falhas deve-se utilizar softwares de

monitoramento para acompanhar o estado da rede. Assim, para garantir os serviços para

qualquer fim que dependam de redes, deve-se acompanhar e verificar constantemente a

funcionalidade do sistema. Estas ferramentas de monitoramento utilizam em sua maioria o

protocolo SNMP (Simple Network Management Protocol) para obter as informações

desejadas, haja visto que a quase totalidade dos equipamentos de rede oferece suporte a este

protocolo.

13

1.3 QUESTÕES DE PESQUISA

Durante a elaboração deste trabalho, procurou-se responder às seguintes questões:

• como é o funcionamento das redes ethernet;

• como monitorar as falhas que podem ocorrer nas redes ethernet;

• como é o funcionamento do protocolo SNMP;

• quais as principais características das MIBs.

1.4 OBJETIVOS DO TRABALHO

Os objetivos deste trabalho estão divididos em objetivo geral e objetivos específicos.

1.4.1 Objetivo geral

Este trabalho tem como objetivo geral estudar e determinar procedimentos de

monitoramento e gerenciamento de falhas em redes ethernet.

1.4.2 Objetivos específicos

O objetivo específico deste trabalho é desenvolver um software de gerência de rede

usando o protocolo SNMP capaz de:

a) obter e tratar informações da rede e de seus elementos;

b) apresentar os alarmes gerados por recursos de rede;

c) identificar o estado das interfaces dos ativos de rede;

d) listar as principais informações dos elementos gerenciados.

14

1.5 ESTRUTURA DO TRABALHO

O trabalho está estruturado em quatro capítulos, sendo o primeiro a introdução que

compreende a justificativa, definição do problema, questões de pesquisa, objetivos do

trabalho e estrutura do trabalho. No segundo capítulo, explana-se a teoria de funcionamento

das redes ethernet e considerações de gerenciamento e arquitetura de redes relevantes para a

fundamentação deste TCC. O desenvolvimento de um protótipo de software de

gerenciamento de rede utilizando como base o protocolo SNMP é descrito no terceiro

capítulo. E por fim, no quarto capítulo, faz-se a conclusão do presente estudo.

15

2 REDES ETHERNET

A evolução dos equipamentos de informática não foi algo que aconteceu rapidamente.

Os equipamentos foram ficando cada vez mais potentes e ao mesmo tempo tornando-se mais

indispensáveis para as empresas e instituições. Cada vez mais se utilizam computadores para

agilizar tarefas do dia a dia através de ferramentas sofisticadas. Para muitas empresas surgiu a

necessidade de que os computadores estivessem ligados de alguma forma aos demais

equipamentos existentes dentro da corporação, otimizando tempo e recursos através do

compartilhamento de impressoras e unidades de backup, não sendo privilégio de alguns, e

sim, estando disponível para todos os usuários (GOETEN, 2001).

Grande parte dos usuários de redes não entende porque precisam dela e, perguntam-se

porque não podem ter os equipamentos desejados em suas máquinas. A falta de treinamento

destes usuários da rede também pode levar ao uso inadequado da mesma, sobrecarregando-a e

conseqüentemente deixando-a mais lenta. Outro aspecto importante é que na maioria dos

casos, as redes não estão somente instaladas em ambientes de trabalho que têm a informática

como sua principal ferramenta (SZTAJNBERG, 1996).

Existem basicamente três tipos de redes de computadores, independentes da tecnologia

utilizada como meio de transmissão:

a) Redes Locais (Local Area Networks – LANs)

As LANs surgiram com o intuito principal de compartilhar recursos em um ambiente

com vários usuários. Um exemplo de utilização das mesmas seriam as empresas, onde vários

usuários, em diferentes estações de trabalho podem utilizar simultaneamente mesmos

programas, impressoras ou servidores. Cada estação de trabalho é independente e a função da

LAN é de integrar estas estações, promovendo uma concentração de recursos e informações,

reduzindo assim os custos para a empresa.

16

Uma rede local é aquela que possibilita a interconexão de equipamentos de

comunicação de dados numa pequena região. As LANs ainda caracterizam-se por não

utilizarem recursos de telecomunicações como meio de transmissão entre seus nós, que

correspondem às próprias estações dos usuários conectados (Goeten, 2001). Isto porque toda a

comunicação ocorre dentro da mesma área, onde os equipamentos estão interconectados

normalmente por concentradores, tornando a rede isenta do uso de recursos como provedores

de acesso à Internet ou serviços de operadoras telefônicas.

Entre as características básicas das LANs, segundo Tanembaum (2003), estão:

a) abrangência geográfica limitada (distâncias menores que 25 Km);

b) altas taxas de transmissão;

c) baixas taxas de erro;

d) possuem pequenos atrasos de transmissão;

e) geralmente são redes privadas;

f) facilidade de interconexão entre redes distintas.

b) Redes Metropolitanas (Metropolitan Area Networks – MANs):

Uma rede metropolitana possui características similares às LANs, mas difere-se por

cobrir uma área física maior que elas. Uma MAN pode cobrir praticamente uma cidade inteira

(TANEMBAUM, 2003).

Como a mais nova das três tecnologias de rede apresentadas, as MANs surgiram com o

objetivo de viabilizar o compartilhamento de recursos de hardware e software entre redes de

uma cidade (SOARES, 1995).

Este tipo de rede tinha uma pequena utilização até o cenário atual devido aos custos e

dificuldades da implantação da mesma. Atualmente com o surgimento de novas tecnologias,

como os sistemas WiMAX (Worldwide Interoperability for Microwave Access -

17

Interoperabilidade Mundial para Acesso de Micro-ondas), redes sem fio de alta capacidade e

ampla cobertura, a criação de redes MANs será mais constante.

c) Redes Geograficamente Distribuídas (Wide Area Networks – WANs)

As WANs são as pioneiras entre as redes de computadores. São constituídas de uma

diversidade de aplicações e usos, destacando-se as redes públicas, isto é, “o sistema de

comunicação é mantido, gerenciado e de propriedade de grandes operadoras (públicas ou

privadas) e seu acesso é público” (SOARES, 1995).

As redes de grande abrangência envolvem grandes distâncias geográficas e a

comunicação ocorre em velocidades mais baixas do que nas redes locais ou nas redes

metropolitanas de computadores (ALBUQUERQUE, 2001). A velocidade inferior, se

comparada as LANs ou MANS, ocorre devido ao compartilhamento em massa dos mesmos

recursos, sobrecarregando os equipamentos e meios de transmissão. Podem-se verificar ainda

os altos custos do serviço, que normalmente inviabilizam projetos de comunicações que

demandam alta capacidade de transmissão.

2.1 GERENCIAMENTO DE REDES

As redes prestam serviços fundamentais na maioria das organizações. As atividades de

algumas dessas organizações se tornam inviáveis se os serviços prestados pela rede não

estiverem disponíveis ou se forem prestados com tempos de resposta acima de determinados

limites. À medida que as redes locais crescem e se interligam com redes de outras

organizações, torna-se necessária a utilização de sistemas que facilitem sua gerência

(ALBUQUERQUE, 2001).

A gerência está associada ao controle de atividades e ao monitoramento do uso de

18

recursos da rede. As tarefas básicas de gerência em redes são: obter informações da rede,

tratar estas informações possibilitando um diagnóstico e encaminhar as soluções dos

problemas (SZTAJNBERG, 1996).

Além dos sistemas de gerenciamento é fundamental que o responsável por uma rede

tenha amplos conhecimentos de procedimentos, desempenho e identificação de falhas que

possam acontecer. Outra característica essencial ao administrador ou gerente de uma rede é a

familiarização com os sistemas por ele utilizados no cotidiano.

Os sistemas usados na gerência de redes procuram prestar os serviços sem

sobrecarregar as entidades gerenciadas ou canais de comunicação e de forma objetiva.

Segundo Tanembaum (2003), os componentes de um sistema de gerenciamento são:

a) dispositivos gerenciados: são dispositivos de hardware, como os computadores,

roteadores e serviços de terminais, que estão conectados à rede;

b) agentes: são programas que residem nos elementos da rede que devem ser

gerenciados. Eles coletam e armazenam diversas informações de gerenciamento;

c) base de informação de gerenciamento (Management Information Base – MIB):

é uma estrutura de dados que contém uma relação dos objetos gerenciáveis. Os

dados contidos nesta estrutura são obtidos pelos agentes e armazenados nesta

estrutura;

d) gerentes: são softwares que concentram os dados obtidos sobre os diversos

dispositivos da rede e os disponibilizam já interpretados para o gerente da rede;

e) protocolos de gerenciamento: através destes protocolos é possível estabelecer a

interação entre os programas gerentes e agentes;

f) interfaces gráficas com o usuário (Graphical User Interface – GUI): nelas a

aplicação disponibiliza de forma amigável os dados e as informações para o

usuário.

19

2.2 MODELO DE GERENCIAMENTO

A gerência de uma rede envolve atividades agrupadas em cindo áreas funcionais

definidas pela ISO no modelo OSI FCAPS: de falhas, de configuração, de desempenho, de

contabilidade e de segurança. As atividades de cada área têm por objetivo controlar a rede,

otimizar a sua utilização e melhorar o desempenho dos serviços prestados aos usuários. A

maioria dos sistemas de gerência não abrange todas as áreas (ALBUQUERQUE, 2001). A

não abrangência de todas as áreas é justificável pela necessidade de objetividade na prática do

gerenciamento. Um sistema de gerência deve ser capaz de transmitir, de forma rápida e clara,

qualquer falha que possa ocorrer na rede. A apresentação de vários dados da rede

simultaneamente promove uma falta de concentração do gerente de rede. Por este motivo a

maioria dos softwares de gerência abrange apenas atividades específicas, como o

gerenciamento de falhas ou desempenho.

O modelo OSI de gerenciamento baseia-se no paradigma da orientação a objetos.

Através de entidades lógicas, também conhecidas como objetos gerenciados, é possível

representar estes recursos gerenciados. Ao desenvolver uma aplicação de gerenciamento, são

utilizados processos distribuídos, que são denominados de gerentes ou monitores,

responsáveis pelo gerenciamento, e agentes, responsáveis pela coleta, armazenamento e

disponibilização das informações (MAFINSKI, 1999).

Segundo Albuquerque (2001), a função de cada área funcional é:

a) gerência de falhas: envolve a identificação e a correção de falhas;

b) gerência de configuração: envolve a análise e a alteração das configurações

das entidades gerenciadas;

c) gerência de desempenho: envolve a coleta de dados sobre o desempenho das

entidades gerenciadas e a execução de ações visando a otimizá-lo;

20

d) gerência de contabilidade: envolve a imposição de cotas aos usuários, a

cobrança pelo uso dos recursos e a sua monitoração;

e) gerência de segurança: envolve o controle do acesso aos recursos, o sigilo, a

autenticação e a identificação de acessos não autorizados.

Os sistemas para gerência de redes podem auxiliar nas diversas fases citadas, coletando

dados e informações sobre eventos ocorridos, apresentando-os em um formato que facilite a

análise, sugerindo procedimentos a serem seguidos, seguindo automaticamente procedimentos

previamente definidos, possibilitando a inspeção e a alteração das configurações das entidades

gerenciadas através da comparação com configurações armazenadas em bases de dados e

possibilitando a modificação de cotas de acordo com as necessidades.

Independente das necessidades do responsável pela gerência da rede, o sistema de

gerenciamento segue um modelo básico. Este pode optar por realizar apenas as gerências

desejadas. No cotidiano a gerência mais utilizada é a de falhas, devido ao impacto que esta

tem sobre o funcionamento de uma rede de computadores. Uma empresa pode, por exemplo,

manter seu funcionamento com uma rede operando com certa lentidão, porém de maneira

alguma conseguirá realizar suas tarefas se a rede sofrer alguma falha e for indisponibilizada.

O modelo básico de gerenciamento é estruturado sobre os elementos de gerente,

agente, biblioteca de dados com informações dos agentes, denominada MIB (Management

Information Base) e protocolo de mensagens, como mostra a figura 1.

Figura 1: Arquitetura dos sistemas de gerência.

Fonte: Acervo do autor.

21

Nas estações de gerência são executados programas que possibilitam controle das

entidades gerenciadas, coleta e análise de dados. Além disso, são armazenadas em arquivos

ou banco de dados as informações sobre as entidades gerenciadas, as quais normalmente

podem ser apresentadas através de diagramas ou gráficos. Quando a atenção do gerente é

necessária, também podem ser gerados alertas sonoros e/ou visuais.

O agente é um programa, instalado e executado nas entidades gerenciadas, que recebe

solicitações da estação de gerência, executa as ações solicitadas e informa à estação sobre

eventos relevantes. Quando um agente recebe uma solicitação, executa a ação após verificar

se a solicitação está correta e se há autorização. Os serviços solicitados resultam na leitura ou

na alteração de dados na entidade gerenciada.

Para que haja comunicação através da rede, além do agente, devem ser instalados

protocolos nas entidades gerenciadas. O mais comum é o protocolo TCP/IP, que pode ser

usado também por outras aplicações na entidade. O código que os implementa normalmente

coleta informações usadas na gerência da rede, como por exemplo, estatísticas associadas a

cada protocolo.

Um sistema para gerência de redes pode ter uma arquitetura centralizada ou

distribuída. Na arquitetura centralizada é usada apenas uma estação de gerência. Os agentes

recebem mensagens dessa estação e executam as ações solicitadas. Essa arquitetura é

adequada para redes de pequeno porte. Na arquitetura distribuída são usadas várias máquinas,

organizadas em uma hierarquia, para gerenciar a rede. As máquinas no topo da hierarquia

operam como estações de gerência, apresentando uma visão integrada da rede, e interagem

com as outras máquinas na hierarquia. Independente da arquitetura adotada, as informações

coletadas são geralmente enviadas para um centro de gerência da rede (Network Management

Center) no qual essas informações são processadas e decisões são tomadas pelos técnicos

responsáveis pela gerência da rede (ALBUQUERQUE, 2001).

22

2.3 ARQUITETURA SNMP

O SNMP foi desenvolvido nos anos 80 como resposta para os problemas de

gerenciamento em redes TCP/IP, envolvendo redes heterogêneas, ou seja, onde não existem

apenas equipamentos de um fabricante. Inicialmente foi concebido para ser apenas uma

solução provisória até o desenvolvimento de um protocolo de gerenciamento mais completo,

o CMIP (Common Management Information Protocol). Neste contexto, sem um protocolo

melhor disponível, o SNMP passou a ser o protocolo mais utilizado (MELLO, 2000).

Outro motivo que levou a permanência do protocolo SNMP foi a compatibilidade de

gerenciamento necessária nas redes de computadores. Como o desenvolvimento do CMIP

ocorreu de forma lenta, as grandes empresas começaram a utilizar o protocolo SNMP, já

desenvolvido, para gerenciar seus equipamentos. Até que o novo protocolo fosse finalizado,

milhares de equipamentos já estavam operando baseados no SNMP, o que exigia a

compatibilidade dos novos equipamentos com estes.

Este protocolo, que opera na camada de aplicação, como mostra a Figura 2, pode ser

facilmente implementado e consome poucos recursos das máquinas e dos canais de

comunicação. O código necessário à sua implementação pode ser desenvolvido para

dispositivos com capacidades mínimas de processamento e armazenamento, e a sobrecarga

decorrente do uso do SNMP na rede e nas entidades é pequena (ALBUQUERQUE, 2001).

23

Figura 2 – Protocolo de gerenciamento SNMP.

Fonte: MELLO (2000)

Atualmente existem três versões de SNMP: o SNMPv1, o SNMPv2 e o SNMPv3. O

SNMPv3, implementa as questões de segurança não encontradas nas primeiras versões do

SNMP, além de adicionar novas funcionalidades, onde destacam-se a capacidade de

gerenciamento distribuído, via primitivas de comunicação gerente-gerente, e as formas de

tratamento e transporte de dados (GOETEN, 2001).

Apesar do desenvolvimento da terceira versão do SNMP, SNMPv3, ter ocorrido há

mais de dez anos, este continua em desuso. Isto vem ocorrendo pela complexidade de

implementação dessa versão, causada principalmente pelas exigências físicas do equipamento

a ser gerenciado. Este deve possuir recursos muito mais elevados de processamento para o

correto funcionamento da versão do protocolo. Como uma das principais características do

SNMP é a flexibilidade e baixo consumo de recursos, a terceira geração do protocolo acaba

inviabilizando a implementação do gerenciamento em equipamentos mais simples. No cenário

atual existem apenas algumas fabricantes de equipamentos que estão utilizando esta versão

em seus equipamentos, que possuem seu custo muito maior do que outros que trazem apenas

versões anteriores do SNMP.

Na arquitetura SNMP, a maior parte do processamento ocorre nas estações de gerência

24

e não nas entidades gerenciadas. Essa arquitetura é composta por agentes, estações de

gerência, bases de dados com informações necessárias à gerência e protocolo para a

comunicação entre agentes e estações. O protocolo define as estruturas das mensagens e a

seqüência em que devem ser trocadas informações entre agentes e estações de gerência. São

definidas mensagens para a leitura de informações dos agentes, a escrita de informações nos

agentes e a monitoração de eventos notificados pelos agentes. Os formatos destas mensagens

foram estabelecidos através de uma linguagem formal chamada Abstract Syntax Notation One

(ASN.1) (ALBUQUERQUE, 2001).

O banco de dados que modela o agente SNMP é denominado Management

Information Base (MIB) e sua função básica é estabelecer quais valores podem ser

gerenciados no dispositivo. O SNMP permite a extensão destes valores padrões

adicionalmente com valores específicos para um agente particular pelo uso de MIB privados.

Diretivas emitidas pelo gerenciador da rede a um agente SNMP consistem nos identificadores

de variáveis de SNMP (chamados identificadores da MIB ou variáveis da MIB) junto com

instruções para adquirir o valor do identificador ou fixar o identificador para um novo valor

(MELLO, 2000).

2.3.1 PONTOS POSITIVOS E NEGATIVOS DO SNMP

O SNMP tem vários pontos positivos. Um deles é sua popularidade para a gerência de

redes TCP/IP. Agentes SNMP estão disponíveis para vários dispositivos de rede, desde

computadores até bridges, modems ou impressoras (STALLINGS, 1999).

Adicionalmente, o SNMP é um protocolo de gerenciamento flexível e extensível.

Pode-se estender os agentes SNMP para cobrir dados específicos de dispositivos, pelo uso de

arquivos ASN.1. O SNMP pode assumir numerosos trabalhos específicos para classes de

25

dispositivos fornecendo um mecanismo padrão de controle de rede e monitoramento

(MELLO, 2000).

Quanto aos pontos negativos do SNMP, estes podem ser descritos principalmente pela

utilização de grandes pacotes para pequenas informações e falhas de segurança. A utilização

de pacotes de tamanho excessivo ocorre principalmente pela forma como são identificados os

objetos de gerenciamento. Estes objetos recebem nomenclaturas em forma de uma seqüência

de bit, onde cada bit representa uma especificação da MIB. Dessa forma existe um tráfego

desnecessário de informações na rede.

Outra deficiência do SNMP padrão está nas brechas de segurança que podem permitir

o acesso de intrusos às informações transportadas pela rede. Esses intrusos podem, portanto,

acessando estas informações, retirar algumas máquinas da rede. A solução para este problema,

no entanto, é simples: a expansão do SNMP, a versão SNMPv3, adiciona mecanismos de

segurança que auxiliam no combate dos três maiores problemas de segurança: a privacidade

dos dados (previne que intrusos tenham acesso às informações de gerenciamento

transportadas pela rede), autenticação (previne que intrusos enviem dados falsos através da

rede) e controle de acesso (restringe o acesso a determinadas variáveis para certos usuários,

reduzindo a possibilidade de um usuário, acidentalmente, danificar a rede) (GOETEN, 2001).

O protocolo SNMP está longe da perfeição, contudo, devido a sua flexibilidade, os

principais problemas relatados podem ser contornados e por isto é utilizado desde a década de

80 pelas grandes ou pequenas empresas fabricantes de equipamentos.

2.3.2 EXTENSÕES AO SNMP

Com sua facilidade de implementação, livrando os desenvolvedores das dificuldades

de compatibilidade do modelo OSI, o protocolo SNMP progrediu rapidamente, tornando-se

26

cada vez mais atraente para o gerenciamento de redes TCP/IP. Com isso, o SNMP ganhou um

número de implementações por parte de diversos fabricantes, tornando-se o protocolo mais

difundido para o gerenciamento de redes (GOETEN, 2001). Apesar de sua criação na década

de 80 e poucas mudanças que ocorreram posteriormente, este protocolo continua atual e supre

as necessidades nas práticas de gerenciamento.

Com a grande popularidade do SNMP, várias extensões têm sido propostas. Talvez a

mais importante das iniciativas seja o desenvolvimento da capacidade de monitoramento

remoto ao SNMP. A especificação Remote Monitoring (RMON) defini capacidades adicionais

à MIB convencional do SNMP, além de funções que exploram a MIB RMON. O RMON

possibilita ao gerente da rede monitorar as subredes como um todo único. Fornecedores e

usuários vêem no RMON uma extensão essencial ao SNMP. O RMON já está sendo

amplamente explorado, possuindo várias implementações (REKOWSKY, 1999).

Além da RMON, várias outras extensões à MIB do SNMP têm sido desenvolvidas.

Algumas dessas extensões buscam compatibilizar o SNMP com outras padronizações, como

Token Ring e FDDI. Outras extensões são específicas de determinados fornecedores e

fabricantes.

2.3.3 MANAGEMENT INFORMATION BASE

A MIB é o conjunto dos objetos gerenciados que traz todas as informações necessárias

para o gerenciamento. Ela contém uma lista de variáveis, denominadas de objetos, e seus

respectivos atributos. O principal requisito para o correto funcionamento do gerenciamento é

a estrutura da MIB contemplar os recursos disponíveis do equipamento gerenciado e estes

recursos poderem ser lidos pelo gerente de rede. Por este motivo surgiu a necessidade de

padronizar uma lista de objetos, que deu origem a MIB.

27

Historicamente a MIB foi desenvolvida em duas etapas. A primeira delas foi

apresentada pela RFC (Request for Comments) 1156 trazendo a MIB primeira versão. Logo

após foram contempladas algumas melhorias na estrutura desta MIB que deram origem a

MIB-2, através da RFC 1213, utilizada atualmente.

O protocolo SNMP utiliza uma MIB padrão, que é conhecida como Structure of

Management Information (SMI). Nessa estrutura, somente cinco tipos de dados são

permitidos: integer, bit string, octet string, null e object identifier. A partir destes tipos

primitivos citados acima, podem ser construídos objetos mais complexos. A variável Object

Identifier oferece uma forma de identificar objetos. O mecanismo utilizado é definir uma

árvore de padrões e colocar todos os objetos de cada padrão em um único local na árvore. Na

figura 3 pode-se ver parte da árvore que inclui a MIB do SNMP (SCHULZ, 2004).

Figura 3 – SMI: MIB padrão SNMP.

Fonte: Schulz (2004)

Segundo Schulz (2004), o nó raiz da árvore não possui rótulo, mas possui pelo menos

três sub níveis, sendo eles: o nó 0 que é administrado pela Consultative Committe for

28

International Telegraph and Thelephone (CCITT), o nó 1 que é administrado pela ISO e o nó

2 que é administrado em conjunto pela CCITT e pela ISO. Sob o nó ISO fica o nó que pode

ser utilizado por outras instituições: o org (3). Abaixo dele fica o DOD (6) que pertence ao

Departamento de Defesa dos EUA. O DOD definiu seis árvores, na qual um sub-nó para a

comunidade Internet, que é administrado pela International Activities Board (IAB). Abaixo

desse nó tem-se:

• directory (1): mantém informações sobre o X.500, serviço de diretórios da ISO;

• mgmt (2): contém as informações de gerenciamento. É nesta árvore que fica o nó da

MIB-2 da internet;

• experimental (3): contém projetos experimentais da IAB;

• private (4): contém objetos definidos por organizações privadas;

• security (5): objetos definidos especificamente para assuntos de segurança;

• SNMPv2 (6): objetos definidos especificamente para o SNMPv2.

A análise da estrutura acima revela a origem do Object Identifier. Todos os nós

possuem além do nome um número particular. Este número é utilizado em seqüências para

identificar os objetos de interesse. Dessa forma, os objetos da MIB SMI são sempre

identificados com o prefixo 1.3.6.1.2.1, que resulta da seqüência iso, org, dod, internet, mgmt,

mib-2. Após este prefixo surgem as categorias, que identificam os objetos de cada

equipamento gerenciado. Estas categorias estão listadas no quadro 1.

29

Quadro 1 – Objetos da MIB-2.

Fonte: Schulz (2004).

O grupo System da MIB-2 contém informações como nome do dispositivo, tipo de

equipamento, fabricante, modelo, data de última inicialização. A grupo Interface trata dos

adaptadores de rede, controlando o número de pacotes e bytes enviados e recebidos da rede,

descartes, difusões e tamanho da fila. O grupo Addr-Translation fornece informações sobre o

mapeamento de endereços. O grupo IP trata de todo o tráfego IP recebido e transmitido pelo

equipamento. São especialmente importantes para o gerenciamento de roteadores. O grupo

ICMP se refere a mensagens de erro ICMP registrando quantas mensagens de erro foram

encontradas. O grupo TCP monitora conexões abertas, segmentos enviados e recebidos e

erros. O grupo UDP registra o número de datagramas UDP enviados e recebidos e estatísticas

de erros. O grupo EGP é usado para controlar roteadores compatíveis com este protocolo. O

grupo Transmission é um marcador de lugar para MIBs de meios físicos externos. Por

exemplo, é possível manter estatísticas especificamente relacionadas a Ethernet. O grupo

30

SNMP se destina ao cálculo de estatísticas sobre a operação do próprio SNMP (SCHULZ,

2004).

A definição dos objetos (variáveis) numa MIB do SNMP padrão, segundo Goeten

(2001), contém os seguintes tipos de dados:

a) INTEGER, OCTET, STRING, NULL, OBJECT IDENTIFIER, SET e

SEQUENCE – são tipos universais, de uso geral;

b) IpAddress – um endereço de 32 bits utilizando o formato IP;

c) Counter32 – um inteiro positivo que pode ser incrementado, mas nunca

decrementado. Seu valor máximo é 232 – 1(4.294.967.295). Quando atingir

seu valor máximo é reiniciado em zero;

d) Gauge32 – um inteiro positivo que pode ser incrementado e decrementado.

Seu valor máximo é o mesmo do Counter32. Quando este valor máximo é

alcançado ele não é reiniciado, pois pode ser decrementado;

e) TimeTicks – este inteiro positivo conta, em milésimos de segundos, um

determinado período;

f) Opaque – este tipo permite suportar dados arbitrários. O dado é codificado

como um OCTET STRING para transmissão.

Os objetos apresentados na MIB são classificados basicamente em três grupos: read-

only (apenas leitura), write-only (apenas escrita), read-write (leitura e escrita). Esta

classificação é baseada na forma como o objeto pode ser acessado ou alterado. Um objeto

read-only pode apenas ser lido, sem direito a alteração. Objetos com direito a escrita podem

ter seus valores alterados por meio de comandos SET. Para permitir qualquer tipo de acesso

aos objetos foram atribuídas duas classes de senhas. Estas senhas permitem o acesso de leitura

ou acesso de escrita nos valores da MIB, também são chamadas de communities

(comunidades). Através destas senhas é possível restringir a interação do gerente com os

31

objetos gerenciados. Normalmente os acessos de leitura são liberados para que os usuários e

gerentes com pouca experiência possam consultar informações sobre o equipamento. O

acesso de escrita nos valores deve ser controlado pelos gerentes de nível superior, pois estes

permitem alteração nas configurações de equipamentos e objetos.

2.3.4 FUNCIONAMENTO DO SNMP

O protocolo SNMP foi desenvolvido para rodar sobre a camada de transporte, na

camada de aplicação da pilha de protocolo TCP/IP. A maioria das implementações do SNMP

utilizam o User Datagram Protocol (UDP) como protocolo de transporte. O UDP é um

protocolo não-confiável, não garantindo a entrega, a ordem ou a proteção contra duplicação

das mensagens (GOETEN, 2001).

O SNMP utiliza o UDP, pois foi desenvolvido para funcionar sobre um serviço de

transporte sem conexão (MELLO, 2000). Foi adotada a utilização do UDP principalmente

para não comprometer o desempenho da rede por onde trafegam as informações de

gerenciamento. Como é exigido do serviço de gerenciamento, que este seja o mais rápido

possível e sem comprometer desempenho, não seria eficiente utilizar um protocolo que

dependesse de um serviço orientado a conexão ou que necessitasse de confirmações a cada

mensagem. Estas confirmações gerariam um tráfego desnecessário na rede, comprometendo

seu desempenho.

Como o UDP é um protocolo não-confiável, é possível que mensagens SNMP sejam

perdidas. O SNMP por si só não fornece garantia sobre a entrega das mensagens. As ações a

serem tomadas quando da perda de uma mensagem SNMP não são abordadas pelo padrão

(MELLO, 2000). No entanto, cada software de gerência aborda esta questão de maneira

distinta. Existem casos onde o software ao fazer uma operação de requisição de valores e não

32

consegue obter o valor, utiliza a falha para determinar a indisponibilidade do equipamento e

alertar o gerente. Outra ação tomada é repetir a requisição até que a mesma obtenha o

resultado desejado.

O SNMP utiliza cinco comandos básicos para suas operações. O comando Get-Request

solicita que os nomes das variáveis requeridos sejam explicitamente informados ao gerente. O

comando Get-Next-Request solicita a variável seguinte, permitindo que um gerente percorra a

MIB inteira alfabeticamente. O comando Get-Bulk-Request serve para a transferência de

grandes quantidades de informação, como por exemplo uma tabela de dados. A mensagem

Set-request permite atualizar o valor de uma variável, mudando o estado desta, desde que a

especificação do objeto permita essas atualizações. A mensagem Inform-request tem a

utilidade de informar a um gerente quais as variáveis ele está gerenciando. O comando Trap é

uma mensagem enviada de um agente para um gerente quando acionada.

A Figura 4 ilustra o contexto do protocolo SNMP na pilha de protocolo TCP/IP,

utilizando o UDP como protocolo de transporte.

Figura 4 – Protocolo SNMP sobre a camada de transporte.

Fonte: Mello (2000).

33

As operações de requisição do SNMP como Get, GetNext, GetBulk, Inform e Set

utilizam a porta 161, já operação Trap tem reservada para si a porta 162. Isto ocorre para que

o tráfego seja separado e as informações possam ser transmitidas ou requeridas de forma mais

segura.

A formação das mensagens SNMP é feita, diferente da maioria dos protocolos, de

forma inversa. Primeiramente é formado o pacote com as informações desejadas. Este pacote

recebe então os indicadores de erros e requisições. Por fim o pacote formado recebe o

cabeçalho de versão e comunidade. Tanto a versão como a comunidade devem ser as mesmas

entre o gerente e o elemento gerenciado para que o pacote seja aceito e não descartado.

Figura 5 – Formato das mensagens SNMP.

Fonte: SCHULZ (2004)

34

3 DESENVOLVIMENTO DO APLICATIVO

Neste capítulo são apresentados em síntese o modelo e a especificação do software

proposto neste trabalho.

3.1 REQUISITOS

Com a unificação cada vez mais forte nos serviços de comunicação das empresas em

locais específicos (datacenters), centralizando a gerência das redes e equipamentos em um só

lugar, existe a necessidade do uso de ferramentas que auxiliem no monitoramento dos ativos

de rede espalhados pelas várias áreas, cidades ou países que compõe a estrutura empresarial.

Sendo assim, os softwares devem englobar funcionalidades que ajudem aos gerentes de rede a

monitorar em tempo real as condições de seus equipamentos. Entre essas funcionalidades

podem-se citar os alertas gerados ao sinal de alguma anormalidade, testes de conectividade,

monitoramento de interfaces, localização de ativos, entre outros.

Para atender a todas essas necessidades um dos melhores protocolos de gerenciamento

é o SNMP, visto que sua globalidade e generalidade auxiliam na comunicação das

ferramentas de gerenciamento com os mais diversos tipos de equipamentos e marcas. As

funcionalidades desejadas para este protótipo são:

a) verificação de conectividade com os equipamentos;

b) monitoramento de interfaces variadas;

c) gerenciamento dos alertas e alarmes gerados pelos equipamentos;

d) informações sobre os equipamentos monitorados.

O desenvolvimento do projeto foi baseado principalmente na plataforma de

equipamentos da marca Cisco, porém isso não impede seu funcionamento com apenas alguns

35

ajustes para outras marcas de roteadores, switches, access points, entre outros. Esta

flexibilidade no funcionamento da ferramenta foi conseguido adotando apenas os objetos

padrão da MIB-2.

Para obtenção dos valores através do protocolo SNMP foi utilizado o SNMPWALK,

um programa já desenvolvido e largamente utilizado no ambiente de gerência. Este programa

faz a requisição dos dados através do SNMP por varredura, ou seja, para cada solicitação ele

faz a varredura de todos os componentes e objetos contidos nas mais diversas MIBs dos

equipamentos. Para fazer a requisição do próximo objeto ele utiliza a operação GetNext já

citada anteriormente. Existe a possibilidade de filtrar apenas objetos desejados com a inclusão

do Identificador de Objeto após o comando de walk. Todos os valores obtidos são salvos em

arquivos de texto para que possam ser lidos e trabalhados da melhor forma.

A figura 6 apresenta um exemplo de obtenção dos valores a partir do SNMPWALK

de forma genérica, ou seja, até que o comando GetNext finalize a consulta de todos os

identificadores, o comando continua pesquisando o próximo valor. Quando utilizado nas

operações do software, o SNMPWALK é solicitado pela seguinte sintaxe: snmpwalk [IP]

[SNMP COMMUNITY] [OBJECT IDENTIFIER] > [FILE]. A função de cada campo é a

seguinte:

a) [IP]: endereço IP do equipamento;

b) [SNMP COMMUNITY]: comunidade SNMP de leitura para o equipamento;

c) [OBJECT IDENTIFIER]: identificador do objeto desejado, por exemplo o uptime:

.1.3.6.1.2.1.1.3.0. Se desejar uma varredura de todos os valores basta omitir este

campo.

d) [FILE]: arquivo que receberá todos os valores obtidos pelo SNMPWALK.

36

Figura 6 – Exemplo de aquisição de valores pelo SNMPWALK.

3.2 ESPECIFICAÇÃO

As principais funcionalidades do protótipo utilizam como protocolo o SNMP, que

permite a obtenção das informações necessárias trocadas entre o Gerente (máquina que roda o

software) e os Agentes, que serão considerados os equipamentos monitorados pelo Gerente.

O software está dividido em 4 módulos. São eles:

a) módulo principal – contém os equipamentos cadastrados e gerencia o acesso

aos mesmos;

b) módulo de informações – traz as principais informações de cada

equipamento cadastrado no gerente;

c) módulo de monitoramento de interfaces – permite o monitoramento das

37

interfaces selecionadas, informando seu estado atual;

d) módulo de syslog - recebe os alertas de modificação de equipamentos que

suportam este serviço.

O funcionamento do software é apresentado a seguir através de fluxogramas. A figura

7 mostra os processos contidos no Módulo Principal da ferramenta desenvolvida neste

projeto, cuja interface está apresentada na figura 16. Neste processo é criada a interface

principal do programa, que apresenta os equipamentos gerenciados e também os botões de

acesso às funções do software.

Figura 7 – Fluxograma do Módulo Principal.

Na figura 8 é demonstrado o funcionamento da função INCLUIR, que inclui os

equipamentos na lista de monitoramento.

38

Figura 8 – Fluxograma da função Incluir.

O funcionamento da função EXCLUIR, que exclui os equipamentos da lista de

monitoramento, é apresentado na figura 9.

Figura 9 – Fluxograma da função Excluir.

39

O próximo fluxograma, apresentado na figura 10, representa o funcionamento da

função STATUS. Esta função permite verificar a conectividade com todos os equipamentos

contidos na lista de monitoramento.

Figura 10 – Fluxograma da função Status.

A função de Informações tem seu funcionamento demonstrado pela figura 11. Esta

função obtém os dados principais do elemento selecionado, são eles: Equipamento, Software,

Host, Uptime, Contato e Local.

Figura 11 – Fluxograma da função Informações.

40

A próxima figura, de número 12, demonstra a funcionalidade de Syslog, que recebe

informações diretamente dos equipamentos que tem suporte a essa função.

Figura 12 – Fluxograma da função Syslog.

O funcionamento da função de Interfaces é mostrado pela figura 13. Esta função

apresenta as interfaces possíveis de monitoramento do equipamento e permitem as incluir no

serviço de estado em tempo real. A seguir é apresentada também a função Incluir, na figura

14.

Figura 13 – Fluxograma da função Interfaces.

41

Figura 14 – Fluxograma da função Incluir da função Interfaces.

O monitoramento de interfaces é demonstrado pelo fluxograma da figura 15. Esta

função permite verificar o estado da interface em intervalos de tempo definidos na

configuração do programa.

Figura 15 – Fluxograma da função Status de Interfaces.

As configurações principais do programa são definidas na função de Configurações.

Esta função tem seu funcionamento explicado na figura 16.

42

Figura 16 – Fluxograma da função Configurações.

43

3.3 IMPLEMENTAÇÃO

O módulo principal, mostrado na figura 17, é também a interface principal para o

usuário. Nele estão contidos os equipamentos monitorados, um teste de conectividade para

estes equipamentos e os botões de acesso aos outros módulos.

Figura 17 – Módulo principal do software.

A interface principal traz os endereços dos equipamentos cadastrados, seus locais de

instalação e também o status fornecido pelo botão “Status”. O status é verificado através de

um comando de ping (envio de pacote ICMP) para cada um dos equipamentos. Caso o

resultado do ping seja positivo o equipamento assume o status de “OK”; se o resultado for um

erro, o equipamento que retornou o erro recebe a condição de “FALHA!!!”, que determina

uma falha de conectividade entre a estação gerente e o elemento monitorado. A inclusão de

44

novos equipamentos nessa interface é feita através do botão “Incluir”, que solicita em duas

telas distintas as informações de endereço IP e local de instalção como mostra a figura 18.

Figura 18 – Interfaces para inclusão de equipamentos.

Após solicitados os dados, estes são inclusos em um arquivo que contém todos os

equipamentos cadastrados até então. Uma das primeiras configurações necessárias para o

correto funcionamento do programa é realizada através do botão “Configurações”. Este abre

uma interface que solicita a comunidade SNMP padrão para os elementos cadastrados, o

tempo de polling, ou atualização do status, para as interfaces monitoradas, que deve ser

informado em minutos, e também o endereço de IP da máquina que está executando o

programa, para que possa ser aberta a porta de comunicação utilizada para receber os alertas

do Syslog.

Outro botão constante nesta interface é o “Excluir” que faz a limpeza do elemento

selecionado da base de dados limpando seu registro no arquivo de equipamentos. Em todos os

módulos onde é solicitada a comunidade SNMP para obtenção dos valores, é verificado

inicialmente se o equipamento está ativo e se a comunidade configurada no programa é a

mesma que dá acesso aos equipamentos.

O módulo de informações, mostrado na figura 19, acionado através do botão

“Informações”, traz as informações mais importantes de cada equipamento selecionado. Este

módulo utiliza o protocolo SNMP para obtenção dos valores desejados. Nele estão presentes

as informações de modelo de equipamento, versão do firmware instalado, hostname (nome do

host), tempo de funcionamento (uptime), informação de contato e local de instalação. As

45

últimas quatro informações citadas anteriormente devem estar devidamente configuradas nos

equipamentos a fim de que a leitura dos valores tenha sucesso. Todas as informações

solicitadas ao equipamento pelo protocolo SNMP estão contidos na MIB genérica do mesmo.

Isto possibilita a utilização do protótipo para gerenciamento de várias marcas e modelos de

ativos. Os objetos solicitados são:

a) modelo do equipamento: .1.3.6.1.2.1.1.1.0 (sysDescr);

b) versão do firmware: .1.3.6.1.2.1.1.1.0 (sysDescr);

c) hostname: .1.3.6.1.2.1.1.5.0 (sysName);

d) tempo em atividade: .1.3.6.1.2.1.1.3.0 (sysUpTimeInstance);

e) contato de suporte: .1.3.6.1.2.1.1.4.0 (sysContact);

f) local de instalação: .1.3.6.1.2.1.1.6.0 (sysLocation).

Figura 19 – Interface de informações.

O módulo de monitoramento de interfaces é considerado como mais importante e útil

nesse software. Após selecionado o equipamento desejado e acionado o botão “Interfaces” no

módulo principal, o software faz uma varredura no objeto que descreve todas as interfaces

constantes no equipamento. Esse processo é executado buscando o objeto .1.3.6.1.2.1.2.2.1.2

(ifDescr). Quando obtido o resultado, obtém-se além da descrição de todas as interfaces, as

instâncias a serem monitoras. São essas instâncias, que aparecem ao final da OID requisitada

que descrevem a identificação da interface de maneira numérica. Esta identificação é utilizada

futuramente para decidir qual valor é ou não relevante para o monitoramento. Após obtidas

todas as interfaces (instâncias e descrições) é gerado um arquivo e espelhado o mesmo para

46

uma lista de interfaces com possibilidade de monitoramento. Ao lado desta lista é gerada uma

lista vazia que deverá conter as interfaces a serem monitoradas. A inclusão das interfaces no

monitoramento é feita selecionando-se o objeto e acionando o botão “Incluir =>”, como

mostra a figura 20, que copia a interface desejada para a lista de monitoramento.

Figura 20 – Módulo de seleção de interfaces.

Após a seleção das interfaces desejadas, deve ser acionado o botão “STATUS” que

fechará a interface atual e iniciará uma interface, figura 21, que faz o monitoramento

constante das interfaces selecionadas. O estado das interfaces é verificado através do objeto

ifOperStatus (1.3.6.1.2.1.2.2.1.8). O valor obtido desse objeto pode ter o valor 1 (um) para

interfaces operantes ou 2 (dois) para desconectadas. O intervalo de atualização do estado das

interfaces é definido pelo valor de polling configurado em “Configurações” da interface

principal do programa. Esse valor deve ser informado em forma de minutos. Quando o

período de polling é superado ocorre a renovação da leitura das interfaces, informando se

houve ou não alteração de estado. Para encerrar o monitoramento, deve ser pressionada a tecla

F10.

47

Figura 21 – Módulo de monitoramento de interfaces.

O último módulo do protótipo, o Syslog, serve apenas como registro e informação das

atividades dos equipamentos cadastrados. Nem todos os equipamentos têm suporte a esta

funcionalidade, porém é uma boa opção para equipamentos que não possuem envio de

mensagens de alerta (Traps) via SNMP. Esse módulo utiliza uma conexão de porta UDP

aberta para recepção de informativos em forma de texto. Este módulo depende da

configuração do endereço IP da estação local no módulo de “Configuração”. Fica restrito o

funcionamento ainda a computadores que não possuem bloqueio na porta 514, como por

exemplo um Firewall. Este módulo registra em uma caixa de texto com barra de rolagem

todos os alertas que os equipamentos ativos enviam. É indispensável também a configuração

dos equipamentos para envio de mensagens de Syslog para o endereço IP da estação local.

Um exemplo do funcionamento do módulo é demonstrado na figura 22.

Figura 22 – Módulo de Syslog.

48

Um dos grandes benefícios dos informes através do syslog é a possibilidade de registro

de todos os eventos monitorados pelos equipamentos. Estes registros podem auxiliar na

detecção de algum problema iminente ou registrar algo que ocorreu fora dos olhares do

gerente de rede. A figura 23 demonstra a interface do protótipo totalmente operacional.

Figura 23 – Interface completa do protótipo.

49

4 CONCLUSÃO

Para que uma rede opere em total funcionalidade existe a necessidade do

monitoramento constante do ambiente, a fim de identificar falhas ou possíveis falhas dos

sistemas. O trabalho de gerenciamento desse ambiente torna-se cada vez mais oneroso tanto

para a empresa quanto para os funcionários responsáveis pelo trabalho. Dessa forma, com as

ferramentas de gerenciamento pode-se otimizar o desempenho dos funcionários e evitar

possíveis falhas que venham a prejudicar o andamento dos mais diversos processos

coorporativos.

A utilização da ferramenta SNMPWALK, foi essencial para o desenvolvimento do

software em virtude da falta de conhecimentos avançados na área de programação deste

acadêmico. Por este motivo também, a linguagem de programação adotada foi a proprietária

da ferramenta AutoIT, da AutoITScript.com. Esta linguagem de programação largamente

utilizada em scripts para automação de tarefas tem uma linguagem mais simples para os

leigos, não sendo capaz de realizar tarefas mais elaboradas na área da programação.

Uma simples ferramenta como a desenvolvida neste trabalho de conclusão de curso

pode auxiliar o cotidiano dos gerentes de rede informando-os das modificações de estado de

algum equipamento que já esteja apresentando alguma falha ou que possa estar com o

funcionamento duvidoso.

Em relação a utilização do protocolo SNMP no gerenciamento dos equipamentos a

conclusão é extremamente positiva, uma vez que este protocolo tem um baixo consumo dos

recursos de rede, fornece a mais variada gama de informações relativa aos equipamentos e

tem uma fácil implementação se comparada com os outros protocolos. A estrutura das MIBs é

organizada e de acesso simples, facilitando o entendimento e leitura dos valores desejados. A

implementação de uma MIB padrão que atende a totalidade dos equipamentos auxilia muito

50

na obtenção de informações comuns e de extrema importância para o gerenciamento de redes.

A flexibilidade e recursos do SNMP permitem a criação de ferramentas completas de

gerenciamento que atendem as necessidades principais nesta prática, seja no gerenciamento

de falhas, configuração, desempenho, contabilidade ou segurança.

4.1 EXTENSÕES

Este trabalho pode ser incrementado com o desenvolvimento de uma versão

aprimorada do software, utilizando uma linguagem de programação avançada e

desenvolvendo um ambiente unificado que contemple todos os módulos necessários para o

funcionamento da ferramenta. Com uma linguagem de programação mais avançada será

possível manter o serviço de monitoramento de todos os equipamentos simultaneamente,

evitando a intervenção constante do operador do programa.

Uma boa sugestão é desenvolver um módulo receptor de Traps, ao invés da

implementação do Syslog. Esse módulo facilitaria o monitoramento dos alarmes para os

gerentes de rede, tornando ainda mais precisa e útil a ferramenta.

É válido também a implementação do software utilizando a terceira geração do

protocolo SNMP, o v3, que incorpora funções de autenticação e aplicação mais avançadas. É

importante ressaltar que esta versão do protocolo foi implementada em poucos equipamentos

e de custo elevado, o que dificulta os testes com o protocolo.

51

REFERÊNCIAS BIBLIOGRÁFICAS

ALBUQUERQUE, Fernando. TCP-IP Internet: protocolos & tecnologias. 3. ed. Rio de Janeiro : Axcel Books do Brasil, 2001. xv, 362 p, il.

BRISA, Sociedade Brasileira para Interconexão de Sistemas Abertos. Arquitetura de redes de computadores OSI e TCP/IP. São Paulo: Makron Books; Rio de Janeiro, 1994.

COMER, Douglas; STEVENS, David L. Internetworking with TCP-IP. 3rd ed. Englewood Cliffs, NJ : Prentice Hall, c1995. 3v, il.

GOETEN, Luciano Waltrick; STRINGARI, Sergio; UNIVERSIDADE REGIONAL DE BLUMENAU, Centro de Ciências Exatas e Naturais. Protótipo de um software agente SNMP para rede Windows. , 2001. 73p, il. Orientador: Sérgio Stringari.

MAFINSKI, Andre; STRINGARI, Sergio; UNIVERSIDADE REGIONAL DE BLUMENAU, Centro de Ciencias Exatas e Naturais. Prototipo de software de gerencia SNMP para o ambiente Windows NT. , 1999. v, 58p, il. Orientador: Sergio Stringari.

MELLO, Jorge Lucas de; PERICAS, Francisco Adell; UNIVERSIDADE REGIONAL DE BLUMENAU. Prototipo de um agente SNMP para uma rede local utilizando a plataforma JDMK. , 2000. x, 88p, il. Orientador: Francisco Adell Pericas.

REKOWSKY, Ricardo Henrique; STRINGARI, Sergio; UNIVERSIDADE REGIONAL DE BLUMENAU, Centro de Ciencias Exatas e Naturais. Prototipo de Software para a monitoracao de desempenho de redes, utilizando o RMON. , 1999. 88p, il. Orientador: Sergio Stringari.

SCHULZ, Murilo Alexandre. Protótipo de software de gerência de desempenho de um access point de rede sem fio utilizando o protocolo SNMP. 2004. Trabalho de Conclusão de Curso (Engenharia de Telecomunicações) – Centro de Ciências Tecnológicas, Universidade Regional de Blumenau, Blumenau.

SZTAJNBERG, Alexandre. Gerenciamento de redes – Conceitos básicos sobre os protocolos SNMP e CMIP. Rio de Janeiro, [1996]. Disponível em: <http://www.gta.ufrj.br/~alexszt/ger/snmpcmip.html>. Acesso em: 20 de Outubro de 2007.

SOARES, Luiz Fernando G.; LEMOS, Guido; COLCHER, Sérgio. Redes de computadores: das LANs, MANs e WANs as redes ATM. 2. ed. rev. e ampl. Rio de Janeiro : Campus, 1995. 705p, il.

STALLINGS, William. SNMP, SNMPv2, SNMPv3, and RMON 1 and 2. 3rd ed. Boston : Addison-Wesley, 1999. xv, 619p, il.

52

TANENBAUM, Andrew S. Redes de computadores. Rio de Janeiro : Campus, 2003. 945 p, il. Tradução de: Computers Networks.

53

ANEXO

A seguir são listados os códigos fonte de todos os módulos do software. Estes códigos

estão escritos na linguagem própria do AutoIT. Cada um deles deve ser salvo com extensão

.au3 e compilado no AutoIT, que é gratuito e encontra-se em: http://www.autoitscript.com/.

Para compilação dos módulos deve-se proceder da seguinte forma:

a) abrir o arquivo com extensão .au3 no SciTE, que faz parte do pacote AutoIT;

b) selecionar a opção tools e em seguinda compile;

c) informar o arquivo executável de destino em target e selecionar compile script.

Para o correto funcionamento do software se faz necessária a existência de três pastas

criadas dentro do diretório de instalação: INI, TMP e EXEC. A pasta INI contém dois

arquivos .ini que servirão de base para o programa, o EQUIP.INI e o CONFIG.INI. No

diretório TMP ficarão armazenados os arquivos temporários necessários durante o

funcionamento do software e por fim, na pasta EXEC estará instalado o software

SNMPWALK, disponível em:

http://download.netiq.com/kb/files/NETIQKB46308_snmpwalk.exe . É fundamental para o

funcionamento do programa, que o software SNMPWALK seja renomeado para

snmpwalk.exe.

O conteúdo dos aquivos .INI em forma de texto é o seguinte:

a) EQUIP.INI:

[IP_LOCAL]

b) CONFIG.INI:

[CONFIG] COMUNIDADE= POLLING= IP=

MÓDULO PRINCIPAL:

54

#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=TELA_PRINCIPAL.exe #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #include <GuiListView.au3> #include <file.au3> #include <Date.au3> #include <misc.au3> $TELA = GUICreate("TCC Mon", 435, 580, 200,100,$WS_SYSMENU) GUICtrlCreateLabel("Elementos gerenciados:",20,10,200,20) $listview = GUICtrlCreateListView("IP |LOCAL |STATUS ", 20, 30, 390, 410) ABRIR() $Btn_DeleteItem = GUICtrlCreateButton("Excluir", 120, 450, 90, 40) $Btn_IncluirItem = GUICtrlCreateButton("Incluir", 20, 450, 90, 40) $Btn_Status = GUICtrlCreateButton("Status", 220, 450, 90, 40) $Btn_Info = GUICtrlCreateButton("Informações", 320, 450, 90, 40) $Btn_Inter = GUICtrlCreateButton("Interfaces", 120, 500, 90, 40) $Btn_Syslog = GUICtrlCreateButton("Syslog", 20, 500, 90, 40) $Btn_Config = GUICtrlCreateButton("Configurações", 220, 500, 90, 40) $Btn_Exit = GUICtrlCreateButton("Sair", 320, 500, 90, 40) GUISetState() While 1 WinSetTitle($TELA, "", "TCC Network Monitor - " & _Now() & "") $msg = GUIGetMsg() Select Case $msg = $GUI_EVENT_CLOSE Or $msg = $Btn_Exit ProcessClose("INFO.EXE") ProcessClose("SELETOR.EXE") ProcessClose("SYSLOG.EXE") ProcessClose("STATUS_INT.EXE") ProcessClose("INFO.EXE") ExitLoop Case $msg = $Btn_DeleteItem EXCLUIR () Case $msg = $Btn_Status STATUS () Case $msg = $Btn_IncluirItem INCLUIR () Case $msg = $GUI_EVENT_CLOSE Or $msg = $Btn_Exit ExitLoop Case $msg = $Btn_Info INFO () Case $msg = $Btn_Inter INTER () Case $msg = $Btn_Syslog SYSLOG () Case $msg = $Btn_Config run("CONFIG.EXE") EndSelect WEnd Func EXCLUIR () $Output_item = GUICtrlRead($listview) If $Output_item <> 0 Then $RESULTADO = StringSplit (GUICtrlRead(GUICtrlRead($listview)),"|")

55

_GUICtrlListViewDeleteItem ($listview, Int(GUICtrlRead($Output_item))) IniWrite ("INI\EQUIP.ini","IP_LOCAL",$RESULTADO[1],"") FileClose("INI\EQUIP.ini") EndIf _GUICtrlListViewDeleteAllItems($listview) ABRIR() EndFunc Func INCLUIR () $IP = InputBox (" TCC Network Monitor ","Favor digitar o IP do equipamento:","","") $LOCAL = InputBox (" LOCAL ","Favor digitar o local:","","") if $IP = '' Or $LOCAL = '' Then MsgBox (0,"ERRO","FAVOR PREENCHER OS CAMPOS IP E LOCAL") Else _GUICtrlListViewInsertItem ($listview, 0, $IP&"|"&$LOCAL) IniWrite("INI\EQUIP.ini","IP_LOCAL",$IP,$LOCAL) EndIf _GUICtrlListViewDeleteAllItems($listview) ABRIR() EndFunc Func STATUS () $FILE_EQUIP = FileOpen ("INI\EQUIP.ini",0) While 1 $LINE_EQUIP = FileReadLine ($FILE_EQUIP) If @error = -1 Then ExitLoop If StringInStr ($LINE_EQUIP,"=") Then $SPLIT_EQUIP = StringSplit ($LINE_EQUIP,"=") If $SPLIT_EQUIP[2] <> "" Then If Ping($SPLIT_EQUIP[1],3000)=0 Then _GUICtrlListViewDeleteItem ($listview, Int(GUICtrlRead(0))) GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2]&"|FALHA!!!", $listview) Else GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2]&"|OK", $listview) _GUICtrlListViewDeleteItem ($listview, Int(GUICtrlRead(0))) EndIf EndIf EndIf WEnd FileClose("INI\EQUIP.ini") EndFunc Func INTER() $IP = StringSplit(GUICtrlRead(GUICtrlRead($listview)),"|") FileClose("INI\IP.TMP") FileDelete("INI\IP.TMP") IniWrite("INI\IP.TMP","IP",$IP[1],' ') Run ("SELETOR.exe") EndFunc Func ABRIR() $FILE_EQUIP = FileOpen ("INI\EQUIP.ini",0) While 1 $LINE_EQUIP = FileReadLine ($FILE_EQUIP) If @error = -1 Then ExitLoop If StringInStr ($LINE_EQUIP,"=") Then $SPLIT_EQUIP = StringSplit ($LINE_EQUIP,"=")

56

If $SPLIT_EQUIP[2] <> "" Then GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2], $listview) EndIf WEnd FileClose("INI\EQUIP.ini") EndFunc Func SYSLOG () Run("SYSLOG.exe") EndFunc Func INFO() $IP = StringSplit(GUICtrlRead(GUICtrlRead($listview)),"|") FileClose("INI\IP.TMP") FileDelete("INI\IP.TMP") IniWrite("INI\IP.TMP","IP",$IP[1],' ') Run("INFO.EXE") EndFunc Exit

57

MÓDULO INFORMAÇÕES: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=INFO.exe #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #include <Process.au3> #NoTrayIcon $IP_TMP = ("INI\IP.TMP") $IP = IniReadSection("INI\IP.TMP","IP") If Ping($IP[1][0],3000)=0 Then MsgBox(16,"FALHA","Falha de comunicação com o equipamento!") Exit Endif $CONFIG = IniReadSection("INI\CONFIG.INI","CONFIG") $COM = $CONFIG[1][1] If @error Then Exit $TELA = GUICreate($IP[1][0], 360, 190,635 , 490,$WS_SYSMENU) GUISetState () _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.1 > TMP\INFO_TEMP.TXT") $TESTE = FileOpen("TMP\INFO_TEMP.TXT",0) $LINE_TESTE = FileReadLine ($TESTE) If $LINE_TESTE = "" Then MsgBox(16,"FALHA","Falha de comunicação com o equipamento! Verifique a comunidade SNMP.") FileClose($TESTE) Exit EndIf FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1 $Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") $ArrayF=StringSplit($Array[2],",") IniWrite("INI\INFO.ini","INFO","EQUIPAMENTO",$ArrayF[2]) WEnd FileClose($TempFile) FileDelete("TMP\INFO_TEMP.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.1 > TMP\INFO_TEMP.TXT") FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1

58

$Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") $ArrayF=StringSplit($Array[2],",") IniWrite("INI\INFO.ini","INFO","SOFTWARE",$ArrayF[3]) WEnd FileClose($TempFile) FileDelete("TMP\INFO_TEMP.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.5 > TMP\INFO_TEMP.TXT") FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1 $Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") IniWrite("INI\INFO.ini","INFO","HOST",$Array[2]) WEnd FileClose($TempFile) FileDelete("TMP\INFO_TEMP.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.3 > TMP\INFO_TEMP.TXT") FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1 $Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array2 = StringSplit($Array[2], ')') IniWrite("INI\INFO.ini","INFO","UPTIME",$Array2[2]) WEnd FileClose($TempFile) FileDelete("TMP\INFO_TEMP.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.4 > TMP\INFO_TEMP.TXT") FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1 $Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") IniWrite("INI\INFO.ini","INFO","CONTATO",$Array[2]) WEnd FileClose($TempFile)

59

FileDelete("TMP\INFO_TEMP.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.1.6 > TMP\INFO_TEMP.TXT") FileWrite("TMP\INFO.INI","") $TempFile = FileOpen ("TMP\INFO_TEMP.TXT",0) $BEGIN=0 While 1 $Linha = FileReadLine($TempFile) If @error = -1 Then ExitLoop $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") IniWrite("INI\INFO.ini","INFO","LOCAL",$Array[2]) WEnd FileClose($TempFile) FileDelete("TMP\INFO_TEMP.TXT") $EQUIP= IniReadSection ("INI\INFO.INI","INFO") GUICtrlCreateLabel ($EQUIP[1][0] & " : " & $EQUIP[1][1],10,15) GUICtrlCreateLabel ($EQUIP[2][0] & " : " & $EQUIP[2][1],10,40) GUICtrlCreateLabel ($EQUIP[3][0] & " : " & $EQUIP[3][1],10,65) GUICtrlCreateLabel ($EQUIP[4][0] & " : " & $EQUIP[4][1],10,90) GUICtrlCreateLabel ($EQUIP[5][0] & " : " & $EQUIP[5][1],10,115) GUICtrlCreateLabel ($EQUIP[6][0] & " : " & $EQUIP[6][1],10,140) While 1 $msg = GUIGetMsg() If $msg = $GUI_EVENT_CLOSE Then Exit WEnd _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.2.2.1.8 > TMP\TEMP1.TXT")

60

MÓDULO SELEÇÃO DE INTERFACES:

#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=SELETOR.exe #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #include <GuiListView.au3> #include <file.au3> #include <Process.au3> #NoTrayIcon GUICreate("Scriptioooo", 730, 400,(@DesktopWidth-730)/2, (@DesktopHeight-400)/2 ) $IP_TMP = ("INI\IP.TMP") $INTER = ("TMP\INTERFACES.TXT") $IP = IniReadSection("INI\IP.TMP","IP") If Ping($IP[1][0],3000)=0 Then MsgBox(16,"FALHA","Falha de comunicação com o equipamento!") Exit Endif $CONFIG = IniReadSection("INI\CONFIG.INI","CONFIG") $COM = $CONFIG[1][1] If @error Then Exit _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.2.2.1.8 > TMP\TEMP1.TXT") $TESTE = FileOpen("TMP\TEMP1.TXT",0) $LINE_TESTE = FileReadLine ($TESTE) If $LINE_TESTE = "" Then MsgBox(16,"FALHA","Falha de comunicação com o equipamento! Verifique a comunidade SNMP.") FileClose($TESTE) Exit EndIf FileDelete("INI\COM.TMP") FileDelete("INI\INTLIST_SELECT.INI") FileDelete("INI\INTLIST_SELECT2.INI") FileDelete("TMP\STATUS.txt") FileWrite("INI\INTLIST_SELECT.INI",'') FileWrite("INI\INTLIST_SELECT2.INI",'') IniWrite("INI\COM.TMP","COMMUNITY",$COM,' ') ;Lê o IP do Equipamento $IP_T = IniReadSection($IP_TMP,"IP") $IP = $IP_T[1][0] ;Faz a coleta das interfaces: _RunDOS ("EXEC\SNMPWALK.exe " & $IP & " " & $COM & " .iso.3.6.1.2.1.2.2.1.2 > TMP\TEMP2.TXT") FileClose($COM)

61

;Lê interfaces FileWrite("TMP\INTERFACES.TXT","") GUICtrlCreateLabel ("Interfaces disponíveis:",40,30) GUICtrlCreateLabel ("Interfaces monitoradas:",430,30) $TempFile = FileOpen ("TMP\TEMP2.TXT",0) $BEGIN=0 While 1 ;Le próxima linha do arquivo temporário $Linha = FileReadLine($TempFile) ;Se der erro (fim do arquivo) sai do loop If @error = -1 Then ExitLoop ;Le próxima linha do arquivo temporário com as interfaces $Array = StringSplit($Linha, '=') $Array[2]=StringReplace (StringReplace ($Array[2]," ",""),'"',"") $IS0=StringSplit($Array[1],".") $ISO_F=$IS0[12] FileWriteLine($INTER,$ISO_F & "=" & $Array[2]) WEnd FileClose($TempFile) $listview_2 = GUICtrlCreateListView("INSTANCIA |DESCRICÃO ", 40, 60, 250, 300) $FILE_EQUIP_2 = FileOpen ($INTER,0) While 1 $LINE_EQUIP_2 = FileReadLine ($FILE_EQUIP_2) If @error = -1 Then ExitLoop If StringInStr ($LINE_EQUIP_2,"=") Then $SPLIT_EQUIP_2 = StringSplit ($LINE_EQUIP_2,"=") If $SPLIT_EQUIP_2[2] <> "" Then GUICtrlCreateListViewItem($SPLIT_EQUIP_2[1]&"|"&$SPLIT_EQUIP_2[2], $listview_2) EndIf WEnd FileClose($INTER) $listview = GUICtrlCreateListView("INSTANCIA |DESCRICÃO ", 430, 60, 250, 300) $Btn_IncluirItem = GUICtrlCreateButton("Incluir =>", 315, 100, 90, 40) $Btn_Exit = GUICtrlCreateButton("SAIR", 315, 280, 90, 40) $Btn_Status = GUICtrlCreateButton("STATUS", 315, 190, 90, 40) GUISetState() While 1 $msg = GUIGetMsg() Select Case $msg = $GUI_EVENT_CLOSE Or $msg = $Btn_Exit CLOSE() ExitLoop Case $msg = $Btn_IncluirItem INCLUIR () Case $msg = $Btn_Status Run ("STATUS_INT.exe") Exit EndSelect WEnd Func INCLUIR ()

62

$Input_item = GUICtrlRead(GUICtrlRead($listview_2)) If $Input_item <> 0 Then $RESULTADO = StringSplit ($Input_item,"|") _GUICtrlListViewInsertItem ($listview, 0, $Input_item) IniWrite ("INI\INTLIST_SELECT.INI","IP_LOCAL",$RESULTADO[1],$RESULTADO[2]) EndIf EndFunc Func CLOSE() FileClose("TMP\TEMP2.TXT") FileClose("TMP\TEMP1.TXT") FileClose("INI\IP.INI") FileClose("TMP\INTERFACES.TXT") FileClose("TMP\STATUS.TXT") FileClose($FILE_EQUIP_2) FileDelete("TMP\TEMP2.TXT") FileDelete("TMP\TEMP1.TXT") FileDelete("INI\IP.INI") FileDelete("TMP\STATUS.TMP") FileDelete("TMP\INTERFACES.TXT") FileWrite("TMP\TEMP2.TXT","") FileWrite("TMP\TEMP1.TXT","") EndFunc Exit

63

MÓDULO MONITOR DE INTERFACES: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=STATUS_INT.EXE #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #include <GuiListView.au3> #include <file.au3> #include <Process.au3> #NoTrayIcon $IP = IniReadSection("INI\IP.TMP","IP") $CONFIG = IniReadSection("INI\CONFIG.INI","CONFIG") $COM = $CONFIG[1][1] GUICreate($IP[1][0] & " - Status das interfaces monitoradas", 360, 390,635 , 100,$WS_MINIMIZEBOX) GUICtrlCreateLabel ("Pressione F10 para fechar...",100,340) _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.2.2.1.8 > TMP\STATUS.TXT") $TESTE = FileOpen("TMP\STATUS.TXT",0) $LINE_TESTE = FileReadLine ($TESTE) If $LINE_TESTE = "" Then MsgBox(16,"FALHA","Falha de comunicação com o equipamento! Verifique a comunidade SNMP.") FileClose($TESTE) Exit EndIf $listview = GUICtrlCreateListView("INSTANCIA |DESCRICÃO |STATUS ", 25, 20, 300, 300) HotKeySet("{F10}", "FIM") GUISetState() While 1 FileCopy("INI\INTLIST_SELECT.INI","INI\INTLIST_SELECT2.INI",1) $FILE_EQUIP = FileOpen ("INI\INTLIST_SELECT2.INI",0) FileClose("INI\INTLIST_SELECT2.INI") While 1 $LINE_EQUIP = FileReadLine ($FILE_EQUIP) If @error = -1 Then ExitLoop If StringInStr ($LINE_EQUIP,"=") Then $SPLIT_EQUIP = StringSplit ($LINE_EQUIP,"=") If $SPLIT_EQUIP[2] <> "" Then $FILE_2 = FileOpen("TMP\STATUS.txt",0) FileClose("TMP\STATUS.TXT") ;~ MsgBox(0,"","abriu o status") While 1 $LINE_2 = FileReadLine($FILE_2) If $LINE_2 = "" Then ExitLoop If @error = -1 Then ExitLoop If StringInStr($LINE_2,"=") Then $SPLIT_2 = StringSplit($LINE_2,"=") $IS0_1 = StringReplace($SPLIT_2[1]," ","") $IS0_2 = StringReplace(".iso.3.6.1.2.1.2.2.1.8."&$SPLIT_EQUIP[1]," ","") ;~ MsgBox(0,"",$IS0_2) If $IS0_1 = $IS0_2 Then If $SPLIT_2[2] = " 1" Then GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2]&"|UP", $listview) Else If $SPLIT_2[2] = " 2" Then

64

GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2]&"|DOWN", $listview) Else GUICtrlCreateListViewItem($SPLIT_EQUIP[1]&"|"&$SPLIT_EQUIP[2]&"|INDEFINIDO", $listview) EndIf EndIf EndIf EndIf WEnd FileClose($FILE_2) EndIf EndIf WEnd FileClose ($FILE_EQUIP) Sleep($CONFIG[2][1]) FileDelete("INI\STATUS.TXT") _RunDOS ("EXEC\SNMPWALK.exe " & $IP[1][0] & " " & $COM &" .1.3.6.1.2.1.2.2.1.8 > TMP\STATUS.TXT") While 1 If (_GUICtrlListViewDeleteItem ($listview,0))=0 Then ExitLoop WEnd WEnd Func FIM() FileClose("TMP\TEMP2.TXT") FileClose("TMP\TEMP1.TXT") FileClose("INI\IP.INI") FileClose("TMP\INTERFACES.TXT") FileClose("TMP\STATUS.TXT") FileDelete("TMP\TEMP2.TXT") FileDelete("TMP\TEMP1.TXT") FileDelete("INI\IP.INI") FileDelete("TMP\STATUS.TMP") FileDelete("TMP\INTERFACES.TXT") FileWrite("TMP\TEMP2.TXT","") FileWrite("TMP\TEMP1.TXT","") Exit EndFunc Exit

65

MÓDULO CONFIGURAÇÕES: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=CONFIG.EXE #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #NoTrayIcon $TELA = GUICreate("Configurações Gerais", 300, 120,(@DesktopWidth-300)/2, (@DesktopHeight-120)/2,$WS_SYSMENU) GUISetState () $CONFIG = IniReadSection ("INI\CONFIG.INI","CONFIG") GUICtrlCreateLabel ("Comunidade SNMP : " & $CONFIG[1][1],10,15) GUICtrlCreateLabel ("Tempo de Polling : " & $CONFIG[2][1],10,40) GUICtrlCreateLabel ("IP da máquina local : " & $CONFIG[3][1],10,65) $ALT_COMM = GUICtrlCreateButton("ALTERAR", 200, 10, 90, 20) $ALT_POLL = GUICtrlCreateButton("ALTERAR", 200, 35, 90, 20) $ALT_IP = GUICtrlCreateButton("ALTERAR", 200, 60, 90, 20) While 1 $msg = GUIGetMsg() Select Case $msg = $GUI_EVENT_CLOSE ExitLoop Case $msg = $ALT_COMM $COMM_1 = InputBox (" TCC Network Monitor ","Favor digitar a comunidade padrão de SNMP dos equipamentos:","","") IniWrite("INI\CONFIG.INI","CONFIG","COMUNIDADE",$COMM_1) GUICtrlCreateLabel (" ",10,15) GUICtrlCreateLabel ("Comunidade SNMP : " & $COMM_1,10,15) Case $msg = $ALT_POLL $POLL_1 = InputBox (" TCC Network Monitor ","Favor digitar o tempo de polling das interfaces (em minutos):","","") IniWrite("INI\CONFIG.INI","CONFIG","POLLING",$POLL_1*60000) GUICtrlCreateLabel (" ",10,40) GUICtrlCreateLabel ("Tempo de Polling (min) : " & $POLL_1,10,40) Case $msg = $ALT_IP $IP_1 = InputBox (" TCC Network Monitor ","Favor digitar endereço da máquina local:","","") IniWrite("INI\CONFIG.INI","CONFIG","IP",$IP_1) GUICtrlCreateLabel (" ",10,65) GUICtrlCreateLabel ("IP da máquina local : " & $IP_1,10,65) EndSelect WEnd

66

MÓDULO SYSLOG: #Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_outfile=SYSLOG.exe #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #include <GuiConstants.au3> #NoTrayIcon $CONFIG = IniReadSection("INI\CONFIG.INI","CONFIG") $IP = $CONFIG[3][1] GuiCreate("TCC Monitor - SYSLOG", 795, 100, 200,680, $WS_SYSMENU) $Edit_1 = GuiCtrlCreateEdit("", 0, 0, 790, 85) UDPStartup() $array = UDPBind($IP, 514) If $array = -1 Then MsgBox(0, "WSAGetLastError", @Error) GuiSetState() While 1 $msg = UDPRecv($array, 100) If $msg <> "" Then GUICtrlSetData($Edit_1, GUICtrlRead($Edit_1) & @CRLF & $msg) EndIf If GUIGetMsg() = $GUI_EVENT_CLOSE Then Exit EndIf WEnd Exit Func OnAutoItExit() UDPCloseSocket($array) UDPShutdown() EndFunc

Fi