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:
1.4
•
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.
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: readonly (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
20, 30, 390, 410)
|STATUS
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
$FILE_EQUIP_2 = FileOpen ($INTER,0)
", 40, 60, 250, 300)
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
$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 ()
", 430, 60, 250, 300)
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, (@DesktopHeight120)/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
Fi
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