FERRAMENTA PARA GERENCIAMENTO DE FALHAS EM REDE ETHERNET BASEADA EM PROTOCOLO SNMP

Transcrição

1 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

2 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

3 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: Membro: Membro: Prof. Francisco Adell Péricas, Mestre Orientador, FURB Prof. José Gil Fausto Zipf, Mestre FURB Prof. Sérgio Vidal Garcia Oliveira, Doutor FURB Blumenau, 10 de Abril de 2008

4 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.

5 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.

6 Viva como se fosse morrer amanhã e aprenda como se fosse viver para sempre. Mohandas Karamchand Gandhi

7 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.

8 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.

9 LISTA DE ILUSTRAÇÕES Figura 1: Arquitetura dos sistemas de gerência Figura 2 Protocolo de gerenciamento SNMP Figura 3 SMI: MIB padrão SNMP Quadro 1 Objetos da MIB Figura 4 Protocolo SNMP sobre a camada de transporte Figura 5 Formato das mensagens SNMP Figura 6 Exemplo de aquisição de valores pelo SNMPWALK Figura 7 Fluxograma do Módulo Principal Figura 8 Fluxograma da função Incluir Figura 9 Fluxograma da função Excluir Figura 10 Fluxograma da função Status Figura 11 Fluxograma da função Informações Figura 12 Fluxograma da função Syslog Figura 13 Fluxograma da função Interfaces Figura 14 Fluxograma da função Incluir da função Interfaces Figura 15 Fluxograma da função Status de Interfaces Figura 16 Fluxograma da função Configurações Figura 17 Módulo principal do software Figura 18 Interfaces para inclusão de equipamentos Figura 19 Interface de informações Figura 20 Módulo de seleção de interfaces Figura 21 Módulo de monitoramento de interfaces Figura 22 Módulo de Syslog Figura 23 Interface completa do protótipo

10 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

11 SUMÁRIO 1 INTRODUÇÃO JUSTIFICATIVA DEFINIÇÃO DO PROBLEMA QUESTÕES DE PESQUISA OBJETIVOS DO TRABALHO Objetivo geral Objetivos específicos ESTRUTURA DO TRABALHO REDES ETHERNET GERENCIAMENTO DE REDES MODELO DE GERENCIAMENTO ARQUITETURA SNMP PONTOS POSITIVOS E NEGATIVOS DO SNMP EXTENSÕES AO SNMP MANAGEMENT INFORMATION BASE FUNCIONAMENTO DO SNMP DESENVOLVIMENTO DO APLICATIVO REQUISITOS ESPECIFICAÇÃO IMPLEMENTAÇÃO CONCLUSÃO EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS ANEXO... 53

12 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).

13 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.

14 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 Objetivo geral Este trabalho tem como objetivo geral estudar e determinar procedimentos de monitoramento e gerenciamento de falhas em redes ethernet 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.

15 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.

16 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.

17 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 -

18 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

19 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.

20 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;

21 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. Fonte: Acervo do autor. Figura 1: Arquitetura dos sistemas de gerência.

22 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).

23 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).

24 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

25 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) 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

26 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 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

27 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 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.

28 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). Fonte: Schulz (2004) Figura 3 SMI: MIB padrão SNMP. 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

29 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 , 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.

30 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

31 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 é ( ). 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

32 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 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

33 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. Fonte: Mello (2000). Figura 4 Protocolo SNMP sobre a camada de transporte.

34 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. Fonte: SCHULZ (2004) Figura 5 Formato das mensagens SNMP.

35 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

36 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: Se desejar uma varredura de todos os valores basta omitir este campo. d) [FILE]: arquivo que receberá todos os valores obtidos pelo SNMPWALK.

37 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

38 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.

39 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.

40 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.

41 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.

42 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.

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

44 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

45 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

46 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: (sysdescr); b) versão do firmware: (sysdescr); c) hostname: (sysname); d) tempo em atividade: (sysuptimeinstance); e) contato de suporte: (syscontact); f) local de instalação: (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 (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

47 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 ( ). 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.