Monograa de Ps-Graduao Lato Sensu apresentada ao Departamento de Cincia da Computao para obteno do ttulo de Especialista em Administrao em Redes Linux Orientador Prof. DSc. Fernando Cortez Sica Lavras Minas Gerais - Brasil 2005 Jos Messias Alves da Silva Construo de Agentes SNMP em Ambientes Linux Monograa de Ps-Graduao Lato Sensu apresentada ao Departamento de Cincia da Computao para obteno do ttulo de Especialista em Administrao em Redes Linux Aprovada em 17 de Abril de 2005 Prof. Sandro Pereira Melo Prof. Samuel Pereira Dias Prof. DSc. Fernando Cortez Sica (Orientador) Lavras Minas Gerais - Brasil Agradecimentos Talvez, to difcil quanto fazer esta monograa encontrar as palavras certas para agradecer a todos que tornaram mais simples e/ou mais produtiva a realizao desta monograa. Espero que nesses agradecimentos eu possa retribuir, ao menos, um pouco da ateno que me foi dada. Ao meu Orientador Prof. DSc Fernando Cortez Sica por seu apoio, pacincia, sugestes, amizade e orientao segura, fator importante na realizao deste trabalho. Aos meus familiares. Com certeza, aqui faltam palavras para expres- sar o meu agradecimento. Aos meus amigos Joo Almeida e Alexandre Jorge pelo incentivo e sugestes. Aos meus amigos da turma ARL2003s2 que mesmo a distncia, souberam me incentivar. Aos meus amigos pela amizade e pelo incentivo. Ao Professor DSc. Francisco Vieira de Souza e Professor MSc. Magno Alves dos Santos que muito me ajudaram na minha formao acadmica, pessoas que eu posso certamente chamar de amigos. A todos, a minha gratido e muito obrigado. Agradeo sobretudo a Deus por mais esta caminhada que estou concluindo com sucesso em minha vida. v vi Resumo Este trabalho apresenta um estudo sobre protocolo de gerenciamento Simple Network Management Protocol (SNMP), atravs de infor- maes que servem para entendimento dos conceitos bsicos de gerenciamento de redes, expondo tambm as caractersticas e van- tagens que este tipo de controle de rede pode oferecer, bem como a forma de implementar agentes SNMP para dispositivos de uma rede Local rea Network (LAN), utilizado vrias ferramentas. vii viii Abstract This work presents a study about of the management protocol Simple Network Management Protocol (SNMP), through of informations that serves for understanding of basics concepts of management networks, shows too the characteristics and advantages what this type of network control can offers, as well the form of implementation agents SNMP for devices of a Local Area Network (LAN), using several tools. ix No basta ensinar ao homem uma especialidade, porque se tornar assim uma mquina utilizvel e no uma personalidade. necessrio que adquira um sentimento, um senso prtico daquilo que vale a pena ser empreendido, daquilo que belo, do que moralmente correto. (Albert Einstein) 1 2 Lista de Siglas e Abreviaturas ACL Access Control List API Application Program Interface ASCII American Standard Code for Information Interchange ASN.1 Abstract Syntax Notation One CCITT Consultative Committe for International Telegraph and Telephone CMIP Common Management Information Protocol CMIS Common Management Information Service CMISE Common Management Information Service Element CPU Central Processor Unit DES Data Encryption Standard DoS Denial of Service EGP Exterior Gateway Protocol FDDI Fiber Distributed Data Interface FTP File Transfer Protocol GUI Graphic User Interface IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol ISO International Organization for Standardization ITU-T International HTML Hipertext Markup Language HTTP Hipertext Transfer Protocol IAB Internet Activities Board IBM Industrial Business Machine IETF Internet Engineering Task Force IP Internet Protocol ITU-T International Telecommunication Union- Telecommunications Standard- ization Sector LAN Local Area Network MAN Metropolitan Area Network MD5 Message Digest Algorithm 5 MIB Management Information Base MTU Maximum Transmission Unit NMS Network Management Station LAN Local Area Network OID Object Identier OSI Open Systems Interconnection 3 PC Personal Computer PDU Protocol Description Unit RMI Remote Method Invocation PARC Palo Alto Research Center RFC Request for Comments RMON Remote Network Monitoring MIB RPC Remote Procedure Call SHA Secure Hash Algorithm SMI Structure of Management Information SMTP Simple Mail Transfer Protocol SNA System Network Architecture SNMP Simple Network Management Protocol TCP Transmission Control Protocol UDP User Datagram Protocol WAN Wide Area Network 4 Sumrio 1 Introduo 13 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.2 Objetivos Especcos: . . . . . . . . . . . . . . . . . . . 14 1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Descrio dos Captulos Posteriores . . . . . . . . . . . . . . . . 15 2 Gerenciamento de Redes 17 2.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Aplicaes de Gerenciamento de Redes . . . . . . . . . . . . . . 17 2.3 Estrutura de Gerenciamento . . . . . . . . . . . . . . . . . . . . 18 2.4 Forma de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . 19 2.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . 20 3 Base de informao gerencial (MIB) 21 3.1 Introduo e Denio de objetos na MIB . . . . . . . . . . . . . 21 3.1.1 Objetos MIB . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.2 Objetos Discretos da MIB . . . . . . . . . . . . . . . . . 23 3.1.3 Tabelas de Objetos da MIB . . . . . . . . . . . . . . . . . 23 3.1.4 Tipos de Objetos de uma MIB . . . . . . . . . . . . . . . 24 3.2 Acesso a Valores da MIB . . . . . . . . . . . . . . . . . . . . . . 26 3.3 Construo de MIBs . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3.1 Tipos ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.2 Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.1 MIB II . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4.2 Exemplos de Objetos da MIB II . . . . . . . . . . . . . . 34 3.5 A MIB RMON . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5.1 Grupos da MIB RMON . . . . . . . . . . . . . . . . . . 37 5 3.6 Compilador de MIB . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . 39 4 Protocolo de Gerenciamento SNMP 41 4.1 Introduo e Origens . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Caractersticas do protocolo SNMP . . . . . . . . . . . . . . . . . 42 4.2.1 Estaes de gerenciamento SNMP . . . . . . . . . . . . . 43 4.3 Aplicaes SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4 Elementos do SNMP . . . . . . . . . . . . . . . . . . . . . . . . 44 4.4.1 Agentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.4.2 Gerentes . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.5 Operaes SNMP aplicveis s Varivies da MIB . . . . . . . . . 46 4.5.1 Caractersticas Extensveis . . . . . . . . . . . . . . . . . 48 4.6 Funcionamento do Protocolo SNMP . . . . . . . . . . . . . . . . 48 4.6.1 SNMP e o Protocolo TCP/IP . . . . . . . . . . . . . . . . 49 4.6.2 Servio requeridos pelo SNMP . . . . . . . . . . . . . . . 50 4.7 Formato das mensagens UDP . . . . . . . . . . . . . . . . . . . . 51 4.7.1 GetRequest PDU . . . . . . . . . . . . . . . . . . . . . . 53 4.7.2 GetNextRequest PDU . . . . . . . . . . . . . . . . . . . 55 4.7.3 GetBulkRequest PDU . . . . . . . . . . . . . . . . . . . 58 4.7.4 SetRequest PDU . . . . . . . . . . . . . . . . . . . . . . 60 4.7.5 Trap PDU . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.7.6 Trap PDU-v2 . . . . . . . . . . . . . . . . . . . . . . . . 63 4.7.7 InformRequest PDU . . . . . . . . . . . . . . . . . . . . 64 4.7.8 GetResponse PDU . . . . . . . . . . . . . . . . . . . . . 64 4.8 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . 65 5 Desenvolvimento de Agentes SNMP 67 5.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.2 Desenvolvimento de agentes via NET-SNMP . . . . . . . . . . . 68 5.2.1 Congurao do Agente SNMP . . . . . . . . . . . . . . 69 5.3 Escrevendo e Instalando uma nova MIB . . . . . . . . . . . . . . 75 5.3.1 Gerando um esqueleto de cdigo C . . . . . . . . . . . . 75 5.3.2 Congurando a compilao de um novo daemon snmpd . 76 5.3.3 Compilando e instalando o suporte a MIB exemplo . . . . 76 5.3.4 Traps em NET-SNMP . . . . . . . . . . . . . . . . . . . 79 5.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . 79 6 6 Monitoramento e Visualizao atravs do MRTG 81 6.1 Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.2 Download e Instalao . . . . . . . . . . . . . . . . . . . . . . . 81 6.2.1 Download . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.2.2 Compilao e Instalao . . . . . . . . . . . . . . . . . . 82 6.2.3 Congurando o MRTG . . . . . . . . . . . . . . . . . . . 82 6.2.4 Agendando Tarefa para o MRTG . . . . . . . . . . . . . . 84 6.2.5 Execuo . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.3 Visualizao de Relatrios . . . . . . . . . . . . . . . . . . . . . 85 6.4 Outras Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . 87 7 Concluses 89 7.1 Pontos Positivos e Negativos do SNMP . . . . . . . . . . . . . . 90 7.2 Vantagens ao se utilizar SNMP . . . . . . . . . . . . . . . . . . . 90 7.3 Algumas limitaes do SNMPv1 . . . . . . . . . . . . . . . . . . 91 7.4 O Futuro do SNMP (SNMPv3) . . . . . . . . . . . . . . . . . . . 91 7.5 Segurana no Protocolo SNMP . . . . . . . . . . . . . . . . . . . 92 7.6 Resultados Alcanados e Contribuies . . . . . . . . . . . . . . 93 7.7 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A Anexos 97 A.1 Modelo de MIB para Utilizao . . . . . . . . . . . . . . . . . . 97 A.2 Modelo de MIB em C e o seu Cabealho . . . . . . . . . . . . . . 98 7 8 Lista de Figuras 2.1 Modelo tpico de um Sistema de Gerncia de Redes . . . . . . . . 19 2.2 Mensagens em um Protocolo de Gerncia de Redes . . . . . . . . 20 3.1 Exemplo de Construo de Mensagem . . . . . . . . . . . . . . . 30 3.2 Exemplo de construo de OBJECT-TYPE . . . . . . . . . . . . 30 3.3 Exemplo de construo MODULEIDENTITY . . . . . . . . . . . 31 3.4 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5 MIB II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.1 Localizao do Protocolo SNMP no TCP/IP . . . . . . . . . . . . 43 4.2 Protocolo SNMP sobre a Camada de Transporte . . . . . . . . . . 50 4.3 Formato de mensagem SNMP . . . . . . . . . . . . . . . . . . . 52 4.4 Estrutura do Campo variablebindings . . . . . . . . . . . . . . . 53 4.5 Formato da GetRequest PDU . . . . . . . . . . . . . . . . . . . . 54 4.6 Passagem da GetRequest PDU . . . . . . . . . . . . . . . . . . . 54 4.7 Formato da GetNextRequest PDU . . . . . . . . . . . . . . . . . 56 4.8 Passagem da GetNextRequest PDU . . . . . . . . . . . . . . . . . 56 4.9 Formato da GetBulkRequest PDU . . . . . . . . . . . . . . . . . 58 4.10 Passagem da GetBulkRequest PDU . . . . . . . . . . . . . . . . . 60 4.11 Estrutura da SetRequest PDU . . . . . . . . . . . . . . . . . . . . 60 4.12 Passagem da SetRequest PDU . . . . . . . . . . . . . . . . . . . 61 4.13 Estrutura da Trap PDU - SNMP . . . . . . . . . . . . . . . . . . 62 4.14 Passagem da Trap PDU . . . . . . . . . . . . . . . . . . . . . . . 63 4.15 Estrutura da Trap PDU - SNMPv2 . . . . . . . . . . . . . . . . . 64 4.16 Estrutura da InformRequest PDU . . . . . . . . . . . . . . . . . . 64 4.17 Passagem da InformRequest PDU . . . . . . . . . . . . . . . . . 65 5.1 Estrutura de diretrio criada aps instalao Net-SNMP . . . . . . 70 5.2 Passos para instalar no Net-SNMP suporte a Perl . . . . . . . . . 75 5.3 Resumo dos diretrios utilizados com Net-SNMP . . . . . . . . . 77 9 6.1 Passos para compilao e instalao do MRTG . . . . . . . . . . 82 6.2 Exemplo de script para iniciar MRTG . . . . . . . . . . . . . . . 84 6.3 Exemplo de relatrio dirio gerado pela interface eth0 - 3com . . . 85 6.4 Exemplo de relatrio anual gerado pela interface eth0 - 3com . . . 86 6.5 Exemplo de Grco gerado pelo RRDTool a partir de Roteador . . 87 10 Lista de Tabelas 3.1 Grupos da MIB II . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1 Campos de uma mensagem SNMP . . . . . . . . . . . . . . . . . 54 5.1 Comandos do Net-SNMP . . . . . . . . . . . . . . . . . . . . . . 73 6.1 Opes de Congurao do MRTG . . . . . . . . . . . . . . . . . 83 11 12 Captulo 1 Introduo As informaes que circulam em uma rede de computadores devem ser trans- portadas de modo convel e rpido. Para que isso acontea importante que os dados sejam monitorados de maneira que os problemas que porventura possam ex- istir sejam resolvidos rapidamente. Uma rede sem mecanismos de gerncia pode apresentar problemas como congestionamento do trfego, recursos mal utilizados, recursos sobrecarregados, problemas com segurana e outros. Assim, a necessidade de gerenciar falhas, congurao, contabilizao, de- sempenho e segurana tem incentivado o desenvolvimento de vrias ferramentas nos ltimos anos. Uma categoria que se destaca a de ferramentas coma nalidade de monitorar e fornecer estatsticas detalhadas sobre o trfego nesses ambientes, para que se possa, por exemplo, identicar gargalos e caracterizar o trfego. Essas ferramentas se baseiam na anlise individual dos pacotes que trafegam na rede, e acabam se limitando a contabilizar o trfego, classicando-o por remetente, des- tinatrio, protocolo utilizado, entre outros critrios. Ao utilizar uma ferramenta como essa, torna-se difcil identicar problemas relacionados ao comportamento de um protocolo de alto nvel, medir o tempo de resposta de determinada transao e detectar a presena de intrusos na rede. Esta crescente necessidade de gerenciamento fez com que padres para fer- ramentas fossem estabelecidos. Em resposta a esta necessidade surgiram dois padres: Famlia de Protocolos SNMP: o protocolo SNMP (Simple Network Manage- ment Protocol) refere-se a um conjunto de padres para gerenciamento que inclui um protocolo, uma especicao de estrutura de dados, e um conjunto de objetos de dados. Este protocolo hoje j est na sua terceira verso ocial, chamada de SNMPv3. Este o protocolo de gerencia adotado como padro para redes TCP/IP, e que ser tratado neste trabalho. 13 Sistemas de gerenciamento OSI (Open Systems Interconnection): este termo refere-se a um grande conjunto de padres de grande complexidade, que denem aplicaes de propsito geral para gerencia de redes, um servio de gerenciamento e protocolo, uma especicao de estrutura de dados, e um conjunto de objetos de dados. Este conjunto de protocolos conhecido como CMIP [Wil96]. Pela sua complexidade, e pela lentido do processo de padronizao, este sistema de gerenciamento no e muito popular. 1.1 Objetivos 1.1.1 Objetivo Geral O trabalho desenvolvido tem como objetivo estudar e aplicar o protocolo de gerenciamento SNMP atravs da especicao e implementao de uma aplicao agente SNMP, para o gerenciamento de dispositivos de uma rede LAN. Assim, tambm, aprender os conceitos, protocolos, ferramentas e tcnicas utilizados na gerncia de uma rede de computadores. 1.1.2 Objetivos Especcos: Entender a necessidade da gerncia de redes e as reas nas quais a gerncia de redes pode ser decomposta. Entender a arquitetura genrica empregada em solues de gerncia de redes de computadores. Entender a funcionalidade bsica dos componentes utilizados na gerncia de redes, incluindo plataformas e aplicaes de gerncia. Entender a soluo SNMP de gerncia de redes, a mais largamente utilizada no mercado, incluindo o modelo de informao, as MIBs mais importantes e o funcionamento do protocolo SNMP. Entender como agentes e gerentes so implementados na arquitetura SNMP Aprender a especicar uma soluo de gerncia de redes 14 1.2 Metodologia O trabalho foi desenvolvido utilizando os materiais e os mtodos descritos a seguir: Foi realizado um levantamento bibliogrco, na internet e em bibliotecas, de artigos cientcos clssicos e atuais relacionados ao tema; em paralelo, foi realizado um estudo de como seria a gerncia de redes, propriamente dita. Tambmfoi realizado umestudo sobre os impactos do uso de agentes SNMP no mundo. As mudanas que esto ocorrendo, o que est sendo afetado; Ao trmino destas etapas, foi dado incio a um estudo mais detalhado de como desenvolver e escrever MIBs e agentes. Ao nal, foram utilizadas algumas ferramentas que facilitam a criao desses elementos de gerncia, tais como Net-SNMP e MRTG. 1.3 Descrio dos Captulos Posteriores Este trabalho apresenta, no captulo 2, os principais conceitos refentes ao gerenciamento de uma redes de computadores, aplicaes, estrutura e objetivos. O captulo 3 apresenta a denio e as caractersticas principais das MIBs, um dos principais objetos de estudo desta monograa, direcionando-se para a sua con- struo, denio de tabelas e seus tipos. Ocaptulo 4 discorre de forma mais apro- fundada a origem, as caractersticas e a utilizao do protocolo de gerenciamento SNMP, agentes e gerentes, mensagens e seus tipos, encapsulamento e transmisso, sempre buscando enfatizar as suas qualidades e decincias. O captulo 5 abrange o desenvolvimento de agentes SNMP na prtica, enfo- cando a sua implementao em Ambientes Linux, instalao, congurao e uso de ferramenta, exemplos de utilizao, monitoramento de obteno e respostas de mensagens. O captulo 6 enfoca a utilizao da ferramenta MRTG como auxilo ao mon- itoramento e exibio de dados atravs da visualizao de relatrios dos disposi- tivos em que foram implementados SNMP. O captulo 7 dedicado a alguma discusses que envolvem o desenvolvimento de SNMP atualmente, vantagens e desvantagens, limitaes e sobretudo no que se refere segurana deste protocolo. Tambm, este captulo reserva-se a explanao de concluses, relato de contribuies e o anseio de desenvolvimento de trabalhos futuros. 15 16 Captulo 2 Gerenciamento de Redes 2.1 Introduo Os sistemas de rede comerciais existentes atualmente esto se tornando ex- tremamente complexos. Partindo de algumas poucas redes locais isoladas, esses sistemas se expandiram em LANs que operam ao longo de corporaes inteiras. Roteadores conectam LANs escritrios remotos e redes de alcance mundial se tornam cada vez mais presentes. Monitorar e fazer manuteno desses sistemas, para no mencionar problemas isolados, pode ser um desao. Entre as atividades bsicas do gerenciamento de redes esto a deteco e cor- reo de falhas, em um tempo mnimo, e no estabelecimento de procedimentos para a previso de problemas futuros. Por exemplo, monitorando linhas cujo trfego esteja aumentando ou roteadores que estejam se sobrecarregando, pos- svel tomar medidas que evitem o colapso da rede, como a recongurao das rotas ou troca do roteador por um modelo mais adequado. 2.2 Aplicaes de Gerenciamento de Redes Devido intensa presso colocada sobre os administradores de rede para que estabeleam um grau de controle sobre a vasta quantidade de produtos LAN het- erogneos que orescem nos sistemas de computao atuais, os sistemas de geren- ciamento de rede passaram a merecer uma considerao maior. Sistemas de gerenciamento de rede empregam um software que controla e ad- ministra uma rede de uma simples estao de trabalho. Alguns sistemas so ex- tremamente simples, usam um sistema bsico e so fceis de operar, dada sua interface amigvel. O problema com a simplicidade que, s vezes, determinados aspectos da rede podem ser sacricados. 17 2.3 Estrutura de Gerenciamento Hoje em dia existe uma grande diversidade de ambientes de rede podendo se encontrar tanto um mainframe IBM com rede SNA (System Network Architecture, arquitetura proprietria da IBM) como uma rede local comambiente Linux. Diante de tal heterogeneidade, a diculdade de se projetar um gerenciamento de rede pode ser grande, implicando o uso de vrias ferramentas inseridas em uma estrutura possivelmente complexa e com limites de atuao denidos entre os componentes envolvidos. Essa estrutura deve ser capaz de estabelecer a estratgia empregada no atendi- mento chamadas dos usurios, assim como a atuao do pessoal envolvido nas tarefas de gerenciamento de rede, alm de denir os supridores de servios, inclu- sive externos e outros aspectos da rede. Portanto, fundamental que haja organi- zao, sendo que alguns aspectos como o atendimento aos usurios demonstram ser primordiais para o sucesso da estrutura. Tambm, desejvel que haja para o usurio um nico ponto de contato para reportar problemas e mudanas. Os limites de atuao da gerncia devem considerar a amplitude desejada pelo modelo j instalado que, alm de operar a rede, deve englobar, dentre outros, os seguintes itens : Controle de acesso rede Disponibilidade e desempenho Documentao de congurao Gerncia de mudanas Planejamento de capacidades Auxlio ao usurio Gerncia de problemas Controle de inventrio A nfase relativa atribuda em cada uma dessas categorias por uma instalao depende do tamaho e complexidade da rede. De um ponto de vista tcnico, observa-se que as redes de computadores es- to em constante expanso, tanto sicamente como em complexidade. Entretanto, para o usurio nal a rede vista como algo muito simples, ou seja, apenas supri- dor de ferramentas que facilitam suas atividades cotidianas. 18 Desta forma, para o usurio, os sistemas de computao devem ser capazes de auxili-lo a atingir vrios objetivos tais como vendas, qualidade, ecincia, no sendo importante a forma como se obtm tais resultados. Entretanto, as dicul- dades se concentram em como avaliar o impacto de uma eventual parada no com- putador central, se a paralisao for apenas parcial ou total ou apenas uma linha ou uma workstation. Este e outros aspectos devem ser abordados dentro do processo de elaborao de um modelo para gerenciamento de redes, visto que constituem o alicerce para a elaborao da estrutura. 2.4 Forma de Gerenciamento De acordo com [DW], um sistema de gerenciamento composto por entidades que participam do processo obtendo informaes ou fornecendo informaes. Em geral, centraliza-se o poder para coleta de informaes a um gerente e agentes - cam responsveis por enviarem informaes a este gerente. Na gura 2.1, pode-se ter uma viso de como funciona um sistema de gerenciamento de redes, a comuni- cao entre aplicaes e objetos gerenciados, que sero detalhados mais adiante. Figura 2.1: Modelo tpico de um Sistema de Gerncia de Redes 19 De uma maneira geral, as mensagens partem do gerente para os objetos geren- ciados, obtendo destes as iformaes necessrias ao gerenciamento da rede. Pode- se observar, na gura 2.2, como se d a comunicao entre gerente e agente, os tipos de mensagens que uem entre essas duas entidades. Figura 2.2: Mensagens em um Protocolo de Gerncia de Redes 2.5 Consideraes Finais O contedo apresentado neste captulo visa familiarizar o leitor com as princi- pais idias relacionadas ao gerencimento de redes. Apresentu-se tambm os con- ceitos de gerncia de redes, estrutura de um gerenciamento de redes. claro que o conhecimento literrio descrito neste material apenas uma introduo, sendo aconselhvel a leitura de outros autores, para um maior embasamento sobre o con- tedo. Contudo, o conhecimento heurstico do especialista adquirido pela vivncia em ambientes de redes tambm de grande importncia para a compreenso. Nos prximos Captulos sero apresentadas as informaes relativas a denio da base de informaes gerenciais, um estudo sobre o protocolo SNMP e sobre ferramentas de desenvolvimento de agentes SNMP e visualizao de dados. 20 Captulo 3 Base de informao gerencial (MIB) 3.1 Introduo e Denio de objetos na MIB Um dos fatores mais importantes em sistema de gerenciamento a forma como as informaes sobre os elementos de rede esto armazenadas. Tais informaes precisam estar disponveis segundo um determinado padro para que possam ser reconhecidas e utilizadas por qualquer aplicao. Os objetos so imagens virtuais dos elementos bsicos que se quer monitorar. Um objeto gerenciado a viso abstrata de um recurso real do sistema. Assim, todos os recursos da rede que devemser gerenciados so modelados, e as estruturas dos dados resultantes so os objetos gerenciados. Os objetos gerenciados podem ter permisses para serem lidos ou alterados, sendo que cada leitura representar o estado real do recurso e cada alterao tam- bm ser reetida no prprio recurso. Os objetos so denidos usando a Abstract Syntax Notation One (ASN.1), que ser melhor explicando na subseo 3.3.1 e esto localizados na MIB (Manage- ment Information Base). Dessa forma, a MIB o conjunto dos objetos gerenciados, que procura abranger todas as informaes necessrias para a gerncia da rede. At o presente momento, foram denidos basicamente quatro tipos de MIBs, a MIBI, a MIBII, a MIB experimental e a MIB privada. MIB I - As MIBs do tipo I fornecem informaes gerais sobre os elementos da rede, sem levar em conta as caractersticas especcas dos equipamentos. MIB II ou MIB Padro - considerada uma evoluo da MIB I, fornece 21 informaes gerais de gerenciamento sobre um determinado equipamento gerenciado. possvel atravs das MIBs I e II obter informaes como tipo e status da interface (Ethernet, FDDI, ATM), nmero de pacotes trans- mitidos, nmero de pacotes com erro, endereo IP das rotas, etc. Possui um conjunto de objetos bem denidos, conhecidos e aceitos pelos grupos e padres Internet; MIB Experimental - aquela em que seus componentes (objetos) esto em fase de desenvolvimento e teste, emgeral, eles fornecem caractersticas mais especcas sobre a tecnologia dos meios de transmisso e equipamentos em- pregados. Estas MIBs podem conter informaes especcas sobre outros elementos da rede e gerenciamento de dispositivos que so considerados importantes. MIB Privada - As MIBs privadas ou proprietrias foram elaboradas com o objetivo de atuar sobre um equipamento em especco, possibilitando que detalhes caractersticos do mesmo possam ser obtidos. Desta forma, possvel obter informaes sobre colises, congurao, swap de portas, e muitas outras, de um roteador. Tambm possvel fazer testes, reinicializar ou desabilitar uma ou mais portas do roteador atravm das MIBs privadas. De acordo com [RM01], no modelo SNMP, os recursos de uma rede so rep- resentados como objetos. Cada objeto , essencialmente, uma varivel que rep- resenta um aspecto do dispositivo gerenciado. Todos os objetos (variveis) so armazenados na MIB. 3.1.1 Objetos MIB Para usar o SNMP efetivamente, usurios precisam estar familiarizados com a Base de Informao do Gerenciador SNMP que dene todos os valores de leitura e alterao que o SNMP capaz. Para comear um administrador tem que conhecer a MIB do SNMP do equipamento ou da rede que estiver gerenciando. A MIB organizada em uma estrutura de rvore, semelhante a uma estrutura de diretrio de arquivos em disco. O topo do nvel SNMP comea com o diretrio que con- tm quatro nveis principais: O nvel mgmt, que normalmente contm os objetos padres do SNMP utilizados por todos os dispositivos da rede; o nvel private que contm os objetos especializados denidos pelos fabricantes de equipamentos de rede; os nveis extended e directory que so normalmente destitudos de quaisquer dados ou objetos signicantes [RM01]. 22 3.1.2 Objetos Discretos da MIB Muitos objetos de SNMP so discretos, o operador necessita apenas saber o nome do objeto da MIB e nenhuma outra informao. Objetos discretos repre- sentam freqentemente valores sumrios de um dispositivo, particularmente til por apresentar informao da rede com a nalidade de comparar desempenho de dispositivos de rede. Se a extenso (nmero de instncia) do objeto no especi- cada, pode ser assumido como .0 (ponto-zero). [Yor] 3.1.3 Tabelas de Objetos da MIB Tabela de objetos contm mltiplas partes de dados do gerenciador. Estes ob- jetos so distintos dos itens Discrete adicionando uma extenso . (ponto) para os nomes deles que distinguem o valor particular que referenciado. A extenso . (ponto) se refere ao nmero da instncia de um objeto do SNMP. No caso do objeto Discrete, este nmero de instncia ser zero. No caso da Tabela de objetos, este nmero de instncia ser o ndice na tabela do SNMP. Tabelas de SNMP so tipos especiais de objetos de SNMP que permitem aglutinar de forma estruturada um conjunto de informaes. Por exemplo, SNMP dene o objeto ifDescr como um objeto padro do SNMP que indica a descrio de texto de cada interface apoiada por um dispositivo particular. Considerando que podem ser con- gurados dispositivos de rede com mais de uma interface, este objeto s poderia ser representado como um array [RM01]. Por conveno, objetos SNMP se agrupam sempre em um diretrio de En- trada, dentro de um objeto com uma Tabela (o objeto ifDescr objeto descrito acima, reside no diretrio ifEntry que armazenado no diretrio ifTable. H vrias regras para desenvolver objetos SNMP, como segue [RM01]: ao criar no diretrio de Entrada de uma tabela tem que conter o mesmo nmero de elementos como outros objetos no mesmo diretrio, onde o nmero de uma instncia o mesmo de todas as entradas. Sempre so con- siderados objetos da tabela como ordens paralelas de dados; quando criando um novo objeto de Entrada, o SNMP requer que um valor tenha sido associado com cada entrada da tabela em uma nica mensagem de SNMP (nico PDU). Isto signica que, para criar uma la em uma tabela (pelo comando set no SNMP), um valor deve ser especicado para cada elemento na la; se uma la da tabela pode ser apagada, o SNMP requer pelo menos que para isso um objeto na entrada tenha um elemento de controle, que documen- 23 tado para executar a excluso da tabela. (Isto s se aplica se uma la pode ser excluda, que necessariamente no requerido de uma tabela do SNMP). 3.1.4 Tipos de Objetos de uma MIB Segundo [Dav97], os objetos da MIB tm um tipo especco de valores. O SNMP dene vrios tipos primitivos, como se segue. Tipo de Objetos de Texto Dene-se o tipo DisplayString que pode conter informao textual arbitrria (normalmente para um mximo de 256 caracteres). O texto deve conter somente caracteres de impresso. Exemplos deste tipo de objeto incluem valores sysDescr e ifDescr. Este tipo de objeto bastante utilizado nas MIB. Tipo de Objetos Contadores Dene-se o tipo Counter que um valor numrico que s pode aumentar. Este o tipo mais comum de objeto de SNMP na MIB padro e inclui objetos como ipInReceives, ipOutRequests, e snmpInPkts. Contadores ultrapassam o valor de mximo da varivel, mas nunca podem ser negativos. Tipo de Objetos de Medida Dene-se o tipo Gauge que um valor numrico que pode aumentar ou pode diminuir. Este tipo encontrado em apenas algumas localizaes dentro da MIB padro. Exemplos deste tipo de objeto incluem o objeto tcpCurrEstab. Tipo de Objetos Inteiros Dene-se o tipo Integer que pode conter valores positivos ou negativos. Este valor normalmente fornecido por valores de tipo Counter ou Gauge, mas s vezes expresso em MIB de equipamentos de fabricantes. Tipo de Objetos Enumerados Dene-se um tipo Enumerated Value que associa um campo textual com um valor numrico. Este tipo bastante comum na MIB padro e inclui objetos como ifAdminStatus, cujo valores enumerados, so up(1), down(2), e testing(3). Geral- mente os valores enumerados so formatados da seguinte forma nome(nmero). 24 Tipo de Objetos Tempo Dene-se um tipo TimeTicks que representa um tempo decorrido. Este tempo sempre tem uma resoluo de um centsimo de segundo, at mesmo quando esta resoluo no usada. Administradores de rede freqentemente formatam este valor de tempo como HH:MM:SS:cc para exibio. Por exemplo, o valor sysUp- Time indica o tempo decorrido desde que um dispositivo foi reiniciado. Tipo de Objetos Objeto Dene-se um tipo Object que pode conter o identicador para outro objeto SNMP. Se o objeto nomeado compilado na MIB, o nome geralmente apresen- tado com o mesmo nome no objeto SNMP. Um exemplo deste tipo de objeto a varivel sysObjectID da MIB. Tipo de Objetos Endereo IP Dene-se um tipo IP address, que contm o Endereo IP de um dispositivo de rede. Este tipo de objeto exibido freqentemente como um endereo de IP con- vencional. Exemplos deste tipo de objeto incluem ipRouteDest, ipRouteNextHop e ipRouteMask. Tipo de Objetos Endereo Fsico Dene-se um tipo Physical address, que contm o endereo fsico de um dis- positivo de rede. Gerentes exibem freqentemente este tipo de objeto como uma sucesso de valores hexadecimal, precedidos pela palavra-chave hex:, e separados atravs de dois pontos. Exemplos deste tipo de objeto incluem o objeto ifPhysAd- dress. Tipo de Objetos String Dene-se um tipo String, que contm uma cadeia de caracteres arbitrrios. Quando a cadeia de caracteres contm s caracteres ASCII, os gerentes exibem este valor como uma string de texto. Caso contrrio, gerentes exibem este tipo como uma sucesso de valores hexadecimal, precedidos pela palavra-chave hex:, e separados atravs de dois pontos. Este tipo de valor incomum, mas ocasional- mente encontrado em MIB proprietrias. 25 Tipo de Objetos Tabela O tipo Table um objeto que contm entradas da tabela. Este tipo de objeto sempre um nome intermedirio que contm um diretrio de Entrada e que con- tm vrios objetos da tabela. Tipo de Objetos Auxiliares O tipo Branch um objeto que contm tipos adicionais, tabelas, ou qualquer tipo de objeto listado acima. 3.2 Acesso a Valores da MIB Cada objeto SNMP denido para ter um tipo de acesso somente de leitura, leitura escrita ou apenas escrita. Isso determina se o usurio pode ler o valor de objeto, pode ler e pode escrever o objeto (com um comando set) ou s escrever o objeto [Inc]. Antes que qualquer objeto possa ser lido ou possa ser escrito, o nome comu- nitrio do SNMP deve ser conhecido. Estes nomes comunitrios so congurados pelo administrador, e podem ser vistos como senhas necessrias para anexar dados ao SNMP. No sentido exato, nomes comunitrios existem para permitir que partes da MIB no SNMP, e subconjuntos de objeto sejam referenciados. Como o termo Comunitrio requerido, espera-se que o verdadeiro propsito destes valores se- jam identicar comunitariamente entre os objetos SNMP congurados. Porm, prtica comum fazer estes nomes comunitrios limitarem o acesso da capacidade do SNMP para usurios sem permisso. 3.3 Construo de MIBs As regras de construo das estruturas da MIB so descritas atravs da Struc- ture of Management Information - SMI. Os objetos de uma MIB so especicados de acordo com a ASN.1 - Abstract Syntax Notation One, uma linguagem intro- duzida pela CCITT (hoje ITU-T) nas Recomendaes X208 e X209, e escolhida pela ISO para descrever os tipos de dados usados em SNMP. A notao sinttica abstrata uma forma de descrio abstrata dos dados com o objetivo de no se levar em considerao a estrutura e restries do equipamento no qual est sendo implementada [Dav97]. A estrutura de informaes de gerncia SMI um conjunto de documentos que denem: 26 Forma de identicao e agrupamento das informaes; Sintaxes permitidas; Tipos de dados permitidos. As instncias do objeto so chamadas de variveis. Os objetos so denidos segundo um determinado tipo (Object Type). Esses tipos possuem cinco campos: Nome (Name) - um nome textual, normalmente curto, para o tipo de ob- jeto denominado Descritor de Objeto, o qual corresponde um identicador de objeto. Identicador (Object Identier) - o identicador do objeto, formado por nmeros que so separados por pontos. Sintaxe (Sintax) - uma sintaxe abstrata para um tipo de objeto. Pode ser uma sintaxe construda reunindo tipos bsicos ou uma sintaxe de aplicao tais como Network Adress, IpAddress ou Time Ticks. De uma maneira geral, pode ser: uma sintaxe do tipo simples que pode ser um inteiro, uma string de octetos, um Object Identier ou nulo; pode ser tambm uma sintaxe de aplicao podendo ser um endereo de rede, um contador, uma medida, um intervalo de tempo ou incom- preensvel. Denio - uma descrio textual da semntica de um tipo de objeto. Trata-se de um campo de grande importncia para MIBs que pretendam ser usadas em um ambiente com fabricantes distintos. Acesso - o tipo de controle que se pode ter sobre o objeto, podendo ser: somente leitura, leitura e escrita ou no acessvel. Status - Pode ser obrigatrio, opcional ou obsoleto. DescrPart - Descrio textual do objeto. ReferPart - Referncia a outro objeto de outra MIB. IndexPart - Usado na denio de tabelas. DefValPart - Valor default quando o objeto criado. 27 3.3.1 Tipos ASN.1 O Padro ASN.1 que dene a construo de MIBs possui alguns tipos bsicos que so de enorme importncia para a perfeita simbolizao. Este tipos dividem-se em Primitivos, Denidos e Construtores: Tipos Primitivos INTEGER - inteiro com sinal, como por exemplo, o nmero de interfaces em um sistema. OCTET STRING - uma String que usada para representar um dado hex- adecimal, como o endereo fsico de uma interface. So DisplayString, octetString, PhysAddress. OBJECT IDENTIFIER - uma String de nmeros derivados de uma rvore nomeada, utilizada para identicar um objeto. NULL - usado em GetRequest PDU, que ser melhor detalhada mais adi- ante. ENUMERATED - um conjunto limitado de inteiros com um signicado as- sociado. BOOLEAN - um inteiro com valores true (1) ou false (2). Tipos Denidos Alguns tipos de dados, especcos para aplicaes SNMP, foramacrescentados para compor os tipos primitivos. Entre outros, esto includos neste conjunto: NetworkAddress IpAddress Counter (inteiro que incrementa at um valor mximo e em seguida retorna a zero) Gauge ( inteiro que cresce e descresce) TimeTicks Opaque No SNMPv2 foram adicionados alguns outros tipos de dados: BIT STRING - lista enumerada de ags 28 Integer32 - idntico ao INTEGER, com intervalo de 2 31 a 2 31 1 Counter32 - idntico ao COUNTER, com intervalo de 0 a 2 32 1 Gauge32 - idntico ao GAUGE, com intervalo de 0 a 2 32 1 NsapAddress - para endereos OSI Counter64 - intervalo de 0 a 2 64 Uinteger32 - inteiro sem sinal, com intervalo de 0 a 2 32 1 Tipos Construtores Os tipos construtores permitem denir estruturas complexas a partir de tipos primitivos. Os construtores usados em SNMP so: SEQUENCE - Dene as linhas de uma tabela. Cada entrada em SE- QUENCE uma coluna. uma lista ordenada de tipos de dados. SEQUENCE OF - Tambm dene as linhas de uma tabela. uma lista or- denada de tipos de dados do mesmo tipo, como por exemplo, uma sequncia de inteiros. Denio de Tipos de Dados em ASN.1 A Denio de tipo de dados segundo ASN.1 so escritos da seguinte forma: DatatypeName ::= DEFINITION Por conveno, o primeiro caractere de um nome tipo de dado uma letra maiscula, como por exemplo: RequestID ::= INTEGER Denio de Tipos de Dados Construtores em ASN.1 Para exemplicar a denio de tipos de dados construtores, a gura ?? mostra que o tipo de dado Message formado por trs campos, um INTEGER, um OCTET STRING e um terceiro tipo chamado PDU. 29 Message : : = SEQUENCE { v e r s i o n INTEGER { v e r s i o n 1(0) } , communi t y OCTET STRING, pdu PDU, } Figura 3.1: Exemplo de Construo de Mensagem 3.3.2 Macros Macros so mecanismos que auxiliam na denio dos objetos da MIB, alm de permitirem a expanso do ASN.1. O SNMP utilizar esta caracterstica da lin- guagem para fornecer informaes completas sobre os objetos em uma MIB, como nome do objeto, que tipo ser o objeto, restries de valores, operaes permiti- das para o objeto como somente leitura (read-only), leitura e escrita (read-write), ou no-acessvel (not-accessible), descrio de informaes sobre o objeto. Para tanto, naa denio de MIBs tem-se o uso extensivo da macro OBJECT-TYPE. Algumas dessas informaes podem ser observadas na gura ?? i pAdEnt ReasmMaxSi ze OBJECTTYPE SYNTAX INTEGER ( 0 . . 6 5 5 3 5 ) ACCESS r eadonl y STATUS mandat or y DESCRIPTION " The s i z e of t he l a r g e s t I P dat agr am whi ch t h i s e n t i t y can r eas s embl e from i ncomi ng I P f r agment ed dat agr ams r e c e i v e d on t h i s i n t e r f a c e . " : : = { i pAddr Ent r y 5} Figura 3.2: Exemplo de construo de OBJECT-TYPE De acordo com a denio mostrada na gura ??, tem-se que: O OBJECT IDENTIFIER para ipAdEntReasmMaxSize {ipAddrEntry 5}, que pode ser obtido percorrendo a rvore como 1.3.6.1.2.1.4.20.1.5. A sintaxe SYNTAX , ou tipo de dado, para os possveis valores de um ipAdEntReasmMaxSize INTEGER. 30 O inteiro est no intervalo de 0 a 65535. O acesso ACCESS informa que tipo de operao pode ser realizar sobre o objeto. Para este caso, a estao de gerenciamento pode somente ler o valor, no pode atualiz-lo. O estado STATUS mandatory informa ao implementador que esta varivel deve ser suportada. A descrio DESCRIPTION informa que o valor dessa varivel o tamanho do maior datagrama que pode ser reconstrudo a partir de fragmentos obtidos pela interface. Pode-se ter tambm mdulos, que agrupam objetos com funcionalidades cor- relatas, formando uma MIB. A construo MODULEIDENTITY permite que ob- jetos relacionados entre si sejam agrupados. Alm das denies OBJECTTYPE, a construo MODULEIDENTITY contm informaes de contato com o autor do mdulo, a data da ltima atualizao, um histrico de revises e uma descrio do mdulo. ipMIB MODULEIDENTITY LASTUPDATED "200503160000Z" ORGANIZATION "DMUFPI " CONTACTINFO " Mes s i as Al ves , j me s s i a s @uf pi . br " DESCRIPTION " The MIB modul e f o r managi ng I P and ICMP i mpl e me nt a t i ons , but e xc l udi ng t he management of I P r o u t e s . " REVISION "200503040000Z" DESCRIPTION " The i n i t i a l r e v i s i o n of t h i s MIB modul e was p a r t of MIBII . " : : = {mib2 48} Figura 3.3: Exemplo de construo MODULEIDENTITY 31 As palavras mais usadas na construo de MIBs so BEGIN, DEFINITIONS, END, EXPORTS, IDENTIFIER, IMPORTS, INTEGER, NULL, OBJECT, OCTET, OF, SEQUENCE, STRING e alguns smbolos especiais muito comuns so :, -, , ::=, | . 3.4 Estrutura A rvore hierrquica mostrada pela gura 3.4 foi denida pela ISO representa a estrutura lgica da MIB, mostra o identicador e o nome de cada objeto. Figura 3.4: MIB O n raiz da rvore no possui rtulo mas possui pelo menos trs subnveis, sendo eles: o n 0 que administrado pela Consultative Committe for International Telegraph and Telephone - CCITT, atualmente ITU-T ; o n 1 que administrado pela International Organization for Standartization - ISO; o n 2 que admin- istrado em conjunto pela CCITT e pela ISO. Sob o n ISO ca o n que pode ser utilizado por outras instituies: o org (3), abaixo dele ca o dod (6) que pertence ao departamento de defesa dos EUA. O Departamento de Defesa dos EUA alocou 32 um sub-n para a comunidade internet, que administrado pela International Ac- tivities Board - IAB e abaixo deste n temos, entre outros, os ns: management, experimental e private. Sob o n management cam as informaes de gerenciamento, sob este n que est o n da MIB II. Sob o n experimental esto as MIBs experimentais. Sob o n private ca o n enterprises e sob este n cam os ns das indstrias de equipamentos. Como exemplo de um objeto, pode-se citar o ipInReceives pertencente ao grupo IP: ipInReceives Object Type Object Identier: 1.3.6.1.2.1.4.3 Access: read-only Syntax: Counter32 Description: O nmero total de datagramas que chegam nas interfaces, in- cluindo aqueles com erro. 3.4.1 MIB II Conforme pode-se observar na gura 3.4, a MIB II organizada a partir do n mgmt (management). Abaixo da subrvore MIB II esto os objetos usados para obter informaes especcas dos dispositivos da rede. Esses objetos esto divididos em 10 grupos, que esto presentes na tabela 3.1, obtida de [Dav]. Tabela 3.1: Grupos da MIB II Grupo Informao system (1) informaes bsicas do sistema interfaces (2) interfaces de rede at (3) traduo de endereos ip (4) protocolo ip icmp (5) protocolo icmp tcp (6) protocolo tcp udp (7) protocolo udp egp (8) protocolo egp transmission (10) meios de transmisso snmp (11) protocolo snmp A planicao do n da MIB II ca como est descrita na gura 3.5. 33 Figura 3.5: MIB II 3.4.2 Exemplos de Objetos da MIB II Alguns dos objetos pertencentes aos grupos da MIB II so descritos a seguir: Grupo System(1.3.6.1.2.1.1) - Dene uma lista de objetos pertencentes op- erao do sistema, como o tempo de funcionamento, contato e nome do sistema. sysDescr (1.3.6.1.2.1.1.1) : Descrio textual da unidade. Pode incluir o nome e a verso do hardware, sistema operacional e o programa de rede. sysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares de segundos) desde a ltima reinicializao do gerenciamento do sistema na rede. sysContact (1.3.6.1.2.1.1.4): Texto de identicao do gerente da mquina gerenciada e como contat- lo. Grupo Interfaces (1.3.6.1.2.1.2) - Rastreia o status de cada interface em uma entidade gerenciada. O grupo interfaces monitora as interfaces em funcionamento ou inativas e rastreia aspectos, como octetos enviados e recebidos, erros e elimi- naes. ifNumber (1.3.6.1.2.1.2.1): Nmero de interfaces de rede (no importando seu atual estado) presentes neste sistema. ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface. ifInOctets (1.3.6.1.2.1.2.2.1.10): Nmero total de octetos recebidos pela in- terface. 34 Grupo IP (1.3.6.1.2.1.4) - Rastreia os diversos aspectos do IP, incluindo o roteamento do IP. ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade um gateway. ipInReceives(1.3.6.1.2.1.4.3): Nmero total de datagramas recebidos pelas interfaces, incluindo os recebidos com erro. ipInHdrErrors (1.3.6.1.2.1.4.4): Nmero de datagramas que foram rece- bidos e descartados devido a erros no cabealho IP. Grupo ICMP (1.3.6.1.2.1.5) - Rastreia aspectos como erros do ICMP. icmpInMsgs (1.3.6.1.2.1.5.1): Nmero total de mensagens ICMP recebidas por esta entidade. Incluindo aquelas com erros. icmpOutMsgs (1.3.6.1.2.1.5.14): Nmero total de me nsagens ICMP envi- adas por esta entidade. Incluindo aquelas com erros. Grupo TCP (1.3.6.1.2.1.6) - Rastreia, entre outros aspectos, o estado das conexes TCP (como closed, listen, sysSent, etc). tcpMaxConn (1.3.6.2.1.6.4): Nmero mximo de conexes TCP que esta entidade pode suportar. tcpCurrentEstab (1.3.6.2.1.6.9): Nmero de conexes TCP que esto como estabelecidas ou a espera de fechamento. tcpRetransSegs (1.3.6.2.1.6.12): Nmero total de segmentos retransmitidos. Grupo UDP (1.3.6.1.2.1.7) - Rastreia dados estatsticos do UDP. udpInDatagrams(1.3.6.1.2.1.7.1): Nmero total de datagramas UDP en- tregues aos usurios UDP. udpNoPorts (1.3.6.1.2.1.7.2): Nmero total de datagramas UDP recebidos para os quais no existia aplicao na referida porta. udpLocalPort (1.3.6.1.2.1.7.5.1.2): Nmero da porta do usurio UDP local. Grupo SNMP (1.3.6.1.2.1.11) - Avalia o trfego SNMP. snmpInPkts (1.3.6.1.2.1.11.1): Nmero total de mensagens recebidas pela entidade SNMP. 35 snmpOutPkts (1.3.6.1.2.1.11.2): Nmero total de mensagens enviadas pela entidade SNMP. snmpInTotalReqVars (1.3.6.1.2.1.11.13): Nmero total de objetos da MIB que foram resgatados pela entidade SNMP. 3.5 A MIB RMON A especicao RMON, Remote MONitoring, dene funes padro de mon- itoramento de rede e interfaces para comunicao entre dispositivos baseados em SNMP. A RMON fornece s redes a capacidade de oferecer uma maneira eciente e efetiva de monitorar o comportamento de subredes e ao mesmo tempo de reduzir a carga tanto em outros agentes como estaes. A MIB RMON utiliza um dispositivo do agente conectado uma rede espal- hada para coletar estatsticas de trco de rede. A MIB RMON tambm realiza clculos diretamente no agente e no deixa a cargo do gerenciador para todas as suas funes. Tipicamente, um agente somente responsvel pela informao de gerenciamento que se relaciona com o seu prprio equipamento Sem um funo de monitoramento remoto, se torna difcil, se no impossvel, para um gerente construir um perl de qualquer atividade em uma subrede individual. A MIB RMON pode ser implementada diretamente nas aplicaes hoje ex- istentes e no requer que todo o SNMP v.2 seja usado. Para ser efetiva,deve-se prover uma estao dedicada de gerenciamento utilizando RMON e capacidade do agente deve estar ligada LAN central. Os agentes RMON cam residentes em dispositivos que monitoram cada subrede nas quais eles esto ligados, dessa forma dando ao gerente um monitoramento da camada de rede. Este monitora- mento incli operao off-line, deteco de problemas e reportagem, dados de valores adicionados e suporte mltiplos gerentes. O RMON empregado para estudar o trfego em uma rede como um todo, superando as limitaes da MIB-II onde um gerente SNMP pode obter apenas in- formaes localizadas em um determinado equipamento. Tipicamente, estes mon- itores (tambm chamados de probes) operam em uma rede no modo promscuo, visualizando todos os pacotes que passam atravs dela. A gerncia de redes remotas atravs de agentes remotos (por exemplo, agentes que implementam a MIB RMON) possui cinco funes: Operaes off-line: so as operaes nas quais uma estao de gerencia- mento no necessita estar em contato direto com seus dispositivos de moni- torao remotos. Essa funo na MIB RMON permite que os agentes sejam 36 congurados para realizar diagnsticos e coletar estatsticas continuamente, mesmo que a comunicao entre a estao de gerenciamento no seja pos- svel ou no seja eciente; Monitorao pr-ativa: os recursos disponveis nos monitores so poten- cialmente teis para continuamente executar diagnsticos e manter logs do desempenho da rede. Essas informaes so importantes para desenvolver a funo baseline. A funo baseline refere-se ao fato de manter um histrico da operao normal de uma rede por um tempo estendido, com o objetivo dessas informaes posteriormente serem analisadas para identicar proble- mas potenciais numa rede; Deteco e registro de problemas: o monitor remoto pode fazer o recon- hecimento de determinadas condies, realizando constantes averiguaes; Valorizao dos dados coletados: o monitor pode executar anlises espec- cas nos dados coletados em suas subredes; Mltiplos gerentes: na congurao de uma rede pode haver mais de uma estao de gerenciamento como forma de oferecer maior nvel de disponibil- idade, para executarem diferentes funes ou ainda para gerenciar diferentes departamentos em uma empresa. 3.5.1 Grupos da MIB RMON A MIB RMON est dividida em nove grupos: Grupo Statistics - esse grupo contm estatsticas medidas pelo monitor para cada interface monitorada no dispositivo. Grupo History - esse grupo registra amostras estatsticas periodicamente e as armazena para uma posterior recuperao. Grupo Alarm - esse grupo periodicamente obtm amostras estatsticas de variveis do monitor e as compara com os limiares previamente congura- dos; Grupo Host - esse grupo contm estatsticas associadas a cada host de- scoberto na rede. Os endereos fonte e destino desses hosts so mantidos numa lista e obtidos dos pacotes bons que foram promiscuamente recebidos pela interface. 37 Grupo HostTopN - esse grupo usado para preparar relatrios que especi- cam os principais hosts de uma lista ordenada por uma de suas estatsticas; Grupo Matrix - esse grupo armazena a estatstica do trfego e nmero de erros entre pares de hosts. Grupo Filter - esse grupo permite que os pacotes sejam capturados com uma expresso de ltro arbitrria; Grupo Capture: esse grupo permite que os pacotes sejam capturados so- bre a correspondncia de um ltro e que o sistema de gerenciamento crie mltiplos buffers de captura, controlando se o buffer de monitorao (trace buffer) continua ou interrompe a captura de pacotes quando estiver cheio; Grupo Event: esse grupo controla a gerao e noticao de eventos; 3.6 Compilador de MIB Uma MIB pode ser compilada por um compilador de MIBs de forma que as informaes presentes na MIB estejam disponveis para aplicaes como MIB browsers e graphers. So aplicaes simples que obtm toda a sua capacidade de gerenciamento atravs da anlise de uma MIB, sem interveno humana. Alm de checar a sintaxe de uma MIB, um compilador de MIBs pode gerar automaticamente as estruturas de dados e o cdigo necessrios para que um agente implemente uma determinada MIB. Um compilador de MIBs tambm pode fazer com que as informaes sobre os objetos gerenciados de MIBs proprietrias ou de novas MIBs que sejam padronizadas estejam disponveis para uma aplicao de gerenciamento existente. Aentrada para umcompilador de MIBs uma coleo de mdulos de MIBs es- critos em um subconjunto da linguagem ASN.1. Estes mdulos contm denies de objetos gerenciados que correspondem s informaes sobre os dispositivos da rede que podem ser manipulados atravs do protocolo SNMP. Os compiladores de MIBs podem gerar vrias representaes das denies dos objetos gerenci- ados contidos nas MIBs usadas como entrada. Estas representaes podem ser processadas mais facilmente pelos agentes e aplicaes de gerenciamento do que a representao ASN.1. Algumas destas representaes so declaraes de estruturas de dados em lin- guagens de programao de alto nvel, como C, que podem ser compiladas e lig- adas em uma aplicao de gerenciamento ou agente. Outras so arquivos de dados contendo representaes das denies dos objetos gerenciados que podem ser li- das para a memria por uma aplicao de gerenciamento ou agente em tempo de 38 execuo. Em alguns casos, o compilador de MIBs gera um cdigo de sada que auxilia na implementao das MIBs de entrada. Por exemplo, um compilador de MIBs pode gerar esqueletos de rotinas para a recuperao ou alterao do valor de um objeto gerenciado, ou rotinas para a gerao de Trap-PDUs especcas. A habilidade de reconhecer as descries presentes em uma MIB mecanica- mente muito atraente, principalmente para os fabricantes de aplicaes genricas, pois estas podem cobrir uma grande variedade de agentes de MIBs. Com o grande nmero de MIBs padronizadas e MIBs proprietrias disponveis atualmente, os compiladores de MIBs reduzem o esforo dos fornecedores para manterem suas aplicaes atualizadas. Atualmente os programas de gerenciamento apenas se limitam a coletar e ex- ibir informaes sobre os elementos da rede, sem entretanto analis-las. Assim o papel de compreender o estado atual da rede e de encontrar solues para os prob- lemas cabe mesmo ao administrador. Esse aspecto diculta muito a compreenso de MIBs desconhecidas relativas um dispositivo desconhecido. 3.7 Consideraes Finais Neste captulo foram apresentados alguns conceitos relacionados a construo de bases de informaes gerenciais (MIBs), denio de objetos e acesso a valores, estrutura e tipos de MIBs. Tambm foram descritas as principais caractersticas da linguagem ASN.1 e realizado um detalhado estudo sobre os grupos pertencentes a algumas MIBs, como MIBII e RMON. No prximo captulo so apresentadas algumas denies, conceitos e operaes pertinentes ao protocolo de gerencia- mento SNMP. 39 40 Captulo 4 Protocolo de Gerenciamento SNMP 4.1 Introduo e Origens A necessidade de mecanismos de gerenciamento nas redes baseadas em TCP/IP atendida pelo SNMP (Simple Network Management Protocol) em as- sociao com o esquema de MIB (Management Information Base). A Internet Ac- tivities Board(IAB), o orgo que rege a poltica da Internet e o protocolo TCP/IP, requisitou um comit para rever as opes de gerenciamento de redes. O comit concluiu que o SNMP deveria ser adotado. Esse protocolo baseado no Simple Gateway Management Protocol(SGMP) que havia sido desenvolvido para admin- istrar redes regionais. O comit tambm comeou a trabalhar em um protocolo futuro chamado de Common Management Information Protocol (CMIP). A idia em torno do SNMP era de que ele seria um remdio rpido at que o CMIP estivesse pronto para uso. Isso foi em 1988. Alguns dos objetivos e especicaes no projeto do SNMP foram : Gerenciamento de rede integrado A capacidade de gerenciar redes in- corporando componentes que venham de uma variedade de fabricantes com uma simples aplicao. Interoperabilidade A capacidade de que um equipamento de um vende- dor seja gerenciado pelo equipamento de outro vendedor. Padronizao Padres denem mtodos de comunicao e estruturas de 41 dados de forma que redes no similares possam ser integradas com o geren- ciamento de rede. Custos Reduzir o custo da construo de um agente que suporte o proto- colo; Trfego Reduzir o trfego de mensagens de gerenciamento pela rede necessrias para gerenciar dos recursos da rede; Restries Reduzir o nmero de restries impostas as ferramentas de gerenciamento da rede, devido ao uso de operaes complexas e pouco exveis; Simplicidade de Operaes Apresentar operaes simples de serem en- tendidas, sendo facilmente usadas pelos desenvolvedores de ferramentas de gerenciamento; Atualizao Permitir facilmente a introduo de novas caractersticas e novos objetos no previstos ao se denir o protocolo; Independncia Construir uma arquitetura que seja independente de detal- hes relevantes somente a algumas implementaes particulares. O Simple Network Management Protocol (SNMP) um protocolo da camada de aplicao, como mostrado na Figura 4.1, desenvolvido para facilitar a troca de informaes de gerenciamento entre dispositivos de rede. Estas informaes trans- portadas pelo SNMP (como pacotes por segundo e taxa de erro na rede), permitem aos administradores da rede gerenciar o desempenho da rede de forma remota, encontrando e solucionando os problemas e planejar o crescimento da rede. 4.2 Caractersticas do protocolo SNMP Normalmente, utilizado uma aplicao na mquina do administrador chamado de cliente que se conecta a um ou mais servidores SNMP localizados em mquinas remotas, para executar operaes sobre os objetos gerenciados. O cliente no percebe quando as operaes esto sendo executadas pelo agente sobre os objetos, o que fornece transparncia ao protocolo, o que j no ocorre com outros protocolos de gerncia como CMIP, por exemplo. O SNMP tambm realiza um processo de autenticao para permitir ou no o acesso de clientes aos objetos gerenciados. 42 Figura 4.1: Localizao do Protocolo SNMP no TCP/IP A principal caracterstica do SNMP a simplicidade. Ao invs de apresentar muitos comandos como outros protocolos, ele possui apenas um pequeno conjunto de operaes com funes bsicas de busca/alterao. Atravs do protocolo SNMP, o cliente enviar comandos com duas funes bsicamente: Uma de obteno dos valores dos objetos (funo GET ) e outra de alterao desses valores (funo SET ). ainda previsto um mecanismo de noti- cao de alteraes nos objetos da MIB (TRAP). Tal estrutura torna o protocolo simples,exvel e estvel, pois mantm um formato bsico xo,mesmo que novos objetos sejam implementados ou mesmo que novas operaes sejam denidas, o que poder ser feito utilizando as operaes bsicas. No envio e recepo de mensagens no protocolo, os nomes dos objetos no devem ser expressos na forma textual, mas sim na forma numrica que repre- senta univocamente s diversas instncias existentes, para que se torne o pacote da mensagem SNMP mais compacto. Assim, conforme foi explicado na seo 3.4, o objeto gerencivel iso.org.dod.internet.mgmt.mib.ip.ipInReceives ser repre- sentado na mensagem SNMP como 1.3.6.1.2.1.4.3. Quando a forma numrica do identicador terminar comzero, signica que o objeto a nica instncia existente. 4.2.1 Estaes de gerenciamento SNMP A estao de gerenciamento SNMP uma coleo de aplicaes e banco de dados que controlam um grupo de agentes. Uma estao de gerenciamento de rede composta por 5 componentes, sendo uma interface para o usurio, aplicaes de gerenciamento, um banco de dados, um dispositivo SNMP e um canal de trans- porte/ligao. A interface do usurio permite ao operador mandar comandos de gerencia- 43 mento e receber do agente respostas solicitadas ou no. Tal interface poderia ser em formato texto ou em algum tipo de interface grca para o usurio (Graphic User Interface - GUI). As aplicaes de gerenciamento operam na anlise e processamento da infor- mao de gerenciamento de rede obtida do agente. O banco de dados, ou variveis de interesse, contm todos os nomes, cong- uraes, performances, topologia e dados examinados da rede. O banco de dados separado em categorias que incluem a Management Information Base (MIB), o banco de dados do elemento de rede e o banco de dados da aplicao de gerencia- mento. 4.3 Aplicaes SNMP Vrios produtos tm surgido com a nalidade de gerenciar a rede, quase que em sua totalidade baseados no padro SNMP e CMIP. O sucesso do SNMP se deve ao fato de ele ter sido o primeiro protocolo de gerenciamento acessvel ao pblico, no proprietrio e simples em sua implementao, o que possibilita o gerenciamento efetivo de ambientes com caractersticas no similares. A implantao dos protocolos SNMP foi introduzida pelos fornecedores de gateways, bridges e roteadores. Normalmente, o fornecedor desenvolve o agente SNMP e, posteriormente, uma aplicao de gerenciamento para a estao gerente, sendo que tais produtos funcionam perfeitamente em ambientes GNU/Linux. Em sua realizao, incorporam funes grcas para o operador do centro de controle e incluem muitas vezes bibliotecas e utilitrios que permitam a criao de apli- caes de gerenciamento com caractersticas especcas para alguns componentes da rede. As implementaes bsicas do SNMP permitem ao gerente monitorar e iso- lar falhas, j as aplicaes mais sosticadas permitem gerenciar o desempenho e a congurao da rede. Estas aplicaes, normalmente, incorporam menus e alarmes para melhorar a interao com o prossional de gerncia. 4.4 Elementos do SNMP O SNMP possui uma caracterstica cliente/servidor, onde o cliente seria o gerenciador da rede e o servidor o agente SNMP e a base que modela este agente a MIB. 44 4.4.1 Agentes No modelo de gerenciamento SNMP, hosts, bridges, roteadores, hubs, etc, de- vem ser equipados com agentes SNMP para que possam ser gerenciados pela es- tao de gerenciamento (Network Management Station - NMS) atravs do gerente SNMP. O agente responde a requisies da estao de gerenciamento, que pode ser o envio de informaes de gerncia ou aes sobre as variveis do dispositivo onde est. O funcionamento desta estrutura s possvel graas ao acesso direto MIB que o agente possui, pois todas as informaes de gerncia encontram-se l [Dav97]. Ao receber uma mensagem SNMP do gerente, o agente identica que operao est sendo requisitada e qual(is) a(s) varivel(is) relacionada, e a partir da executa a operao sobre a MIB. Em seguida, monta uma nova mensagem de resposta, que ser enviada ao gerente. primeira vista, a comunicao do agente com o gerente pode parecer injusta uma vez que o agente apenas responde ao que lhe questionado. Mas h momentos em que o agente podefalar espontaneamente com o gerente sem que antes seja questionado. Isso ocorre quando o agente detecta, a partir da anlise do contexto da MIB, alguma situao inesperada. Neste momento, o agente gera uma mensagem especial, o Trap, e a envia ao gerente, relatando sobre a situao. Para o tratamento destas excees e o envio de Trap, concedido ao agente um certo poder de deciso, cabendo a ele, a partir da anlise do contexto da MIB, decidir se ou no necessrio enviar oTrap ao gerente. Esse poder de deciso concedido ao agente para que em certas situaes, como quando da inicializao do sistema, Trap desnecessrios no sejam trafegados pela rede, o que, em se tratando de dezenas de agentes, poderia interferir no desempenho global da rede. Cabe ao agente um papel fundamental em todo o processo de gerenciamento da rede, acessando e disponibilizando informaes de gerncia contidas na MIB, alm de indicar situaes inesperadas de funcionamento do dispositivo que estiver gerenciando atravs do envio de Trap ao gerente. 4.4.2 Gerentes A interface entre as aplicaes de gerncia correntes no NMS e os agentes es- palhados pelos dispositivos da rede o gerente. Cabe ao gerente enviar comandos aos agentes, solicitando informaes sobre variveis de um objeto gerenciado ou modicando o valor de determinada varivel. Os gerentes ento processam estas informaes colhidas pelos agentes e as repassam aplicao que as requisitou. A comunicao entre o gerente e as apli- caes possvel atravs da utilizao das API do gerente SNMP pelo sistema. 45 A API (Application Program Interface) um conjunto de funes que fazem o intermdio na execuo de comandos entre um programa e outro, de forma a simplicar a um programa o acesso a funes de outro programa e que, no caso do SNMP, fazem o intermdio das execues entre uma aplicao de gerncia e o gerente SNMP [And04]. Quando uma solicitao da aplicao de gerncia chega ao gerente, atravs da API, o gerente mapeia esta solicitao para um ou mais comandos SNMP que, atravs da troca de mensagens apropriadas, chegaro aos agentes correspondentes. Deve-se ressaltar que este comando SNMP montado pelo gerente pode ser enviado a umoutro gerente, que pode ou no repass-lo a umagente. S que a comunicao gerente-gerente s possvel na verso estendida do SNMP, o SNMPv2, e no faz parte do SNMP padro. Cabe tambm ao gerente encaminhar aplicao de gerncia os Trap que por- ventura sejam enviados pelos agentes. Assim, o software de gerncia ter conhec- imento da presena de um novo equipamento na rede ou do mal funcionamento de algum dos dispositivos da rede. Quando da inicializao do software de gerncia, nada se sabe sobre a con- gurao ou funcionamento da rede. Essas informaes vo sendo conhecidas atravs de Trap que so enviados pelos agentes. A partir da o gerente realiza polling 1 [And04] a m de manter a comunicao com os agentes, possibilitando ao software de gerncia mapear, monitorar e controlar a rede. 4.5 Operaes SNMP aplicveis s Varivies da MIB No gerenciamento SNMP existem vrias operaes para a comunicao entre os gerentes e agentes SNMP para obter informaes dos dispositivos gerenciados. Get O gerente SNMP envia o comando Get a um determinado agente toda vez que necessita recuperar uma informao de gerenciamento especca do objeto geren- ciado pelo agente. Estas informaes encontram-se na forma bsica de variveis, que por sua vez esto na MIB do elemento de rede gerenciado. 1 Forma de gerenciamento de redes em que o gerente requisita informaes que se encontram nos agentes) 46 GetNext O comando GetNext assemelha-se ao comando Get, no entanto, enquanto o comando Get solicita ao agente a leitura de determinada instncia de uma varivel, ao receber um comando GetNext, o agente deve ler a prxima instncia disponvel, na ordem especicada pela MIB, da(s) varivel(is) associada(s). Esta operao especialmente utilizada na recuperao de uma tabela de in- stncias da MIB cujo tamanho seja desconhecido. Para isto, inicialmente es- pecicado no comando GetNext o nome da tabela, o que retornar como resposta o primeiro item (neste caso, uma instncia de varivel) da tabela. Com o nome do primeiro item da tabela, o gerente pode enviar um outro GetNext, desta vez passando a resposta do GetNext anterior como parmetro, a m de recuperar o prximo item da tabela, e assim sucessivamente at recuperar todas as instncias da varivel na tabela. Para este caso, se o comando Get fosse utilizado ele falharia, pois o nome da tabela no corresponde a uma instncia individual da varivel. Set A operao Set requisita a um determinado agente a atribuio/alterao do valor de determinada(s) varivel(is) de uma MIB. Alguns desenvolvedores, por exemplo, acreditam que este comando no deve retornar um Response. J outros acham que a operao Set deve retornar alguma indicao de que a operao foi efetuada. Porm o mais correto seria que aps cada operao Set sobre uma var- ivel, uma operao Get fosse efetuada sobre a mesma varivel a m de assegurar que a operao Set foi efetuada. Trap Aoperao Trap difere de todas as outras. Ela utilizada por umagente SNMP para noticar de forma assncrona a um gerente algum evento extraordinrio que tenha ocorrido no objeto gerenciado. Diversos questionamentos so feitos quanto a esta operao. Talvez o maior deles seja sobre a escolha dos eventos que devem realmente ser noticados ao gerente. Embora seja quase unnime que o gerente deve ser informado de al- guns eventos signicativos, muitos fornecedores de produtos que implementam o SNMP trazem Traps especcos, muitos deles desnecessrios [Wil96]. Outro importante questionamento como um agente pode ter certeza de que o gerente o recebeu, visto que a operao Trap no gera um Response, o que pode ocorrer quando, por exemplo, a mquina estiver perdendo pacotes. Isso no fcil de solucionar. Uma possibilidade seria o agente gerar tantos Traps quanto 47 necessrio at que o gerente seja informado do evento. Essa soluo, no entanto, aumentaria o trfego na rede, afetando o seu desempenho. Responses Como j descrito, sempre que um agente recebe um comando Get, GetNext ou Set ele tenta executar a operao associada e, conseguindo ou no, constri uma outra mensagem que enviada ao emissor da requisio. Esta mensagem a GetResponse. Das operaes SNMP, apenas o Trap no gera um Response. 4.5.1 Caractersticas Extensveis As caractersticas extensveis do SNMP permite ao usurio estender denies de novas MIB para o sistema. Estas denies normalmente so fornecidas por fabricantes de equipamento de rede, especialmente formatada usando a sintaxe ASN.1, que conforme vista na seo 3.3, uma linguagem de declarao abstrata adotada pelo SNMP. A MIB de um dispositivo SNMP normalmente xa. Ela desenvolvida pelos fabricantes de equipamentos de rede (i.e. fabricante de roteadores, de hardware de computador, etc.) e no pode ser estendida ou modicada. Esta extenso de SNMP se refere estritamente ao software gerenciador SNMP [Inc]. 4.6 Funcionamento do Protocolo SNMP O SNMP foi projetado para ser o mais simples possvel, sendo baseado ape- nas em estaes de gerenciamento de rede e elementos da rede. As estaes de gerenciamento da rede so responsveis por rodar aplicaes de gerenciamento que monitorem e controlem os elementos da rede. Os elementos da rede so hubs inteligentes, roteadores e pontes possuem agentes que esto localizados dentro do limites dos elementos, que so responsveis por realizar as funes que so requi- sitadas pelas estaes de gerenciamento. Cada mquina gerenciada vista como um conjunto de variveis que rep- resentam informaes referentes ao seu estado atual, estas informaes cam disponveis ao gerente atravs de consulta e podem ser alteradas por ele. Cada mquina gerenciada pelo SNMP deve possuir um agente e uma base de infor- maes MIB. O SNMP o meio pelo qual a estao de gerenciamento e os elementos de rede se comunicam. um protocolo simples que permite um administrador inspecionar ou alterar variveis em um elemento de rede a partir de uma estao de gerenciamento remota. 48 Todo o monitoramento SNMP realizado pelo sistema de gerenciamento de rede. As estaes de gerenciamento acessam os elementos de rede para obter a in- formao desejada ou para mudar uma varivel. Nesse caso estar sendo realizada uma operao de polling. O agente um componente que pode ser implementado em hardware ou em software. O que ele realiza na verdade coletar dados de um dispositivo e armazen-los na MIB. 4.6.1 SNMP e o Protocolo TCP/IP O protocolo SNMP foi desenvolvido para rodar sobre a camada de transporte, na camada de aplicao da pilha de protocolo TCP/IP. A maioria das implemen- taes do SNMP utilizam o User Datagram Protocol -UDP como protocolo de transporte. O UDP um protocolo no-convel, no garantindo a entrega, a or- dem ou a proteo contra duplicao das mensagens [Dav97]. O SNMP utiliza o UDP, pois foi desenvolvido para funcionar sobre um servio de transporte sem conexo. A maior razo para isto o desempenho. Utilizando um servio orientado conexo, como o TCP, a execuo de cada operao ne- cessitaria de uma prvia conexo, gerando um overhead signicativo, o que in- aceitvel na atividade de gerncia onde as informaes devem ser trocadas entre as entidades da forma mais rpida possvel, sem afetar o desempenho da trans- misso dos demais dados. Segmentos UDP so transmitidos em datagramas IP. O cabealho UDP inclui os campos de origem e destino, um checksum opcional que protege o cabealho UDP e os dados de usurio (em caso do checksum ser violado, a Protocol Description Unit (PDU) descartada) [Tel] . Duas portas UDP so associadas s operaes SNMP. As operaes Get, Get- Next, GetBulk, Inform e Set utilizam a porta 161. Por ser acionada em casos de exceo, a operao Trap tem reservada para si a porta 162 [And04]. Como o UDP um protocolo no-convel, possvel que mensagens SNMP sejam perdidas. O SNMP por si s no fornece garantia sobre a entrega das men- sagens. As aes a serem tomadas quando da perda de uma mensagem SNMP no so abordadas pelo padro. No entanto, algumas consideraes podem ser feitas sobre a perda de mensagens SNMP. No caso de uma mensagem de Get, GetNext ou GetBulk, a estao de geren- ciamento deve assumir que esta mensagem (ou o GetResponse correspondente) tenha sido perdida se no receber resposta num certo perodo de tempo. A es- tao de gerenciamento ento pode repetir a mensagem uma ou mais vezes at que obtenha a resposta. Desde que um nico request-id(que identica a mensagem) seja utilizado para cada operao distinta, no haver diculdade em identicar mensagens duplicadas. 49 No caso de uma mensagem de Set, a recuperao deve provavelmente envolver o teste no objeto associado operao atravs de uma Get sobre este mesmo objeto a m de determinar se a operao Set foi ou no efetivada. Conforme [Inc], no SNMP o gerente executa o gerenciamento atravs da uti- lizao do protocolo SNMP, que implementado no topo das camadas UDP, IP e do protocolo dependente do tipo de rede (Ethernet, FDDI, X.25, ATM, entre outras). A gura 4.2 ilustra o contexto do protocolo SNMP na pilha de protocolo TCP/IP, utilizando o UDP como protocolo de conexo. Figura 4.2: Protocolo SNMP sobre a Camada de Transporte O SNMP requer alguns servios da camada de transporte para que suas men- sagens sejam transmitidas entre as entidades de gerenciamento. Isso independe da implementao da camada de transporte. 4.6.2 Servio requeridos pelo SNMP Rodando na camada de aplicao da arquitetura TCP/IP, como mostrado na Figura 4.2, o SNMP encontra-se acima das camadas de Transporte e Rede. Para que o SNMP possa funcionar adequadamente, estas camadas (Transporte e Rede) devemfornecer ao menos cinco servios que so de vital importncia transmisso das mensagens SNMP atravs da rede [Inc]: Roteamento - A camada de Rede quem fornece as funes de roteamento, 50 as quais aperfeioam toda a utilidade do gerenciamento da rede, dando a possibilidade de rotear vrias vezes os pacotes em torno de reas da rede com falhas. Isso permite que o gerenciamento da rede continue operando mesmo aps falha em alguma(s) mquina(s) na rede. Independncia do meio - Permite ao SNMP gerenciar diferentes tipos de elementos da rede, de forma independente. Caso o SNMP fosse construdo sobre a camada de enlace, estaria preso a esta implementao de enlace es- pecca, desse modo o SNMP no poderia gerenciar um outro dispositivo que implementasse outro protocolo de enlace, o que limitaria o gerencia- mento da rede. Fragmentao e Remontagem - Este servio est relacionado com a inde- pendncia do meio. A mensagem SNMP pode ser fragmentada em pacotes, transmitida pelo meio e remontada no destino. O protocolo IP permite que os pacotes SNMP trafeguem pelo meio com diferentes tamanhos. A Frag- mentao e a Remontagem reduzem a robustez geral do gerenciamento da rede, pois se qualquer fragmento for perdido pelo caminho, toda a operao ir falhar. Checksum ponto-a-ponto - O checksum ponto-a-ponto um servio de checagem de erros fornecido pela camada de transporte que permite a uma entidade conferir a integridade dos dados recebidos atravs da rede, aumen- tando a conabilidade da transmisso; Multiplexao/Demultiplexao - Os servios de Multiplexao e Demul- tiplexao so fornecidos pelo protocolo de transporte. Estes servios facili- tam em muito os possveis relacionamentos de gerenciamento com o SNMP, permitindo que vrias aplicaes SNMP possam utilizar servios da camada de transporte. 4.7 Formato das mensagens UDP No SNMP, as informaes so trocadas entre os gerentes e agentes na forma de mensagens. Cada mensagem possui duas partes, um cabealho e uma Protocol Data Unit (PDU). O formato geral de uma mensagem SNMP pode ser visualizada na Figura 4.3. version - Indica a verso do protocolo SNMP utilizado. community - O nome de comunidade atua como uma senha para autenticar a mensagem SNMP. 51 Figura 4.3: Formato de mensagem SNMP SNMP PDU - a unidade de dados de protocolo, PDU, utilizada pelo SNMP. Contm os dados referentes a operao desejada (Get, GetNext, etc). O campo PDU pode variar de acordo com o tipo de PDU utilizado em uma mensagem SNMP. As PDU GetRequest PDU, GetNextRequest PDU e SetRequest PDU so denidas no SNMP com o mesmo formato da GetResponse PDU, com os campos error-status e error-index com valor zero. Essas PDU possuem os seguintes campos [Dav97]. 1. PDU type - indica o tipo de PDU, neste caso pode ser uma GetRequest PDU, uma GetNextRequest PDU, uma SetRequest PDU ou uma GetRe- sponse PDU; 2. request-id - Usado para identicar o request. Essa mesma identicao ser utilizada na resposta a esta mensagem; 3. error-status - um sinalizador utilizado para indicar que uma situao in- esperada ou erro ocorreu no processamento da mensagem; seus valores pos- sveis so: (a) noError (0) - Indica que no houve qualquer tipo de erro no processa- mento da mensagem; (b) tooBig (1) - Se o tamanho da mensagem GetResponse gerada exceder uma limitao local, ento o campo error-status assume este valor. Neste caso, o valor do campo error-index deve ser zero; (c) noSuchName (2) - Indica que o valor de alguma varivel da lista de variveis ( variablebindings) no est disponvel na MIB em questo. Neste caso, o valor do campo error-index indica em qual varivel da lista ocorreu o problema; (d) badValue (3) - Signica que o valor para uma determinada varivel da lista no est de acordo com a linguagem ASN.1; ou que o tipo, tamanho ou valor inconsistente. Assim como no caso anterior, o valor do campo error-index indica em qual varivel da lista ocorreu o problema; 52 (e) readOnly (4) - Indica que determinada varivel da lista s pode ser lida e no alterada. Neste caso, esse tipo de cdigo de erro s retornado aps uma operao de Set sobre alguma varivel. O valor do campo error-index indica em qual varivel da lista ocorreu o problema; (f) genErr (5) - Se o valor de uma determinada varivel da lista no puder ser identicado ou alterado por outras razes que no as j citadas, ento o campo error-status assume o valor genErr ou simplesmente 5. Neste caso, o valor do campo error-index indica em qual varivel da lista ocorreu o problema; (g) error-index - Quando o campo error-status diferente de zero, este campo fornece uma informao adicional indicando qual varivel da lista de variveis causou a exceo (ou erro); (h) variablebindings - Uma lista de nomes de variveis e seus respectivos valores (em alguns casos, como no GetRequest PDU, esses valores so nulos). A estrutura deste campo mostrada na Figura 4.4. Figura 4.4: Estrutura do Campo variablebindings Por se tratar de um caso particular de mensagem, indicando uma situao in- esperada, a Trap PDU possui uma estrutura diferente das demais PDU utilizadas pelo SNMP. Pode-se conferir na tabela 4.1, um apanhado dos principais campos de uma menagem SNMP. 4.7.1 GetRequest PDU A GetRequest PDU utilizada pela estao de gerncia SNMP para executar a operao Get, requisitando ao agente SNMP a leitura de variveis da MIB da mquina onde ele se encontra. A entidade emissora inclui os seguintes campos nesta PDU: Percebe-se na Figura 4.5 que na GetRequest PDU os campos error-status e errorindex possuem o valor zero. A entidade SNMP receptora responde a uma GetRequest PDU com uma Ge- tResponse PDU contendo o mesmo valor do request-id, como est mostrando na gura 4.6. Caso a entidade receptora da GetRequest PDU possa fornecer o valor 53 Tabela 4.1: Campos de uma mensagem SNMP Campo Descrio Version Verso SNMP Comunity Comunidade a que pertence um agente SNMP com alguns conjuntos arbitrrios de entidades de aplicao SNMP Request-id Usado para distinguir entre requests Error-status Usado para indicar que uma exceo ocorreu quanto processava um request Error-index Quando um error-status no 0, error-index pode prover informaes adicionais indicando qual varivel na lista causou a exceo Variable-bindings Uma lista de nomes de variveis e valores correspondentes Enterprise Tipo do objeto gerador do Trap Generic-trap Tipo genrico do Trap Specic-trap Cdigo especco do Trap Time-stamp Tempo ocorrido entre ltima inicializao ou reinicializao da rede e a gerao do Trap Figura 4.5: Formato da GetRequest PDU Figura 4.6: Passagem da GetRequest PDU 54 de todas as variveis listadas no campo variablebindings, ento montada uma GetResponse PDU contendo este campo acrescentado do respectivo valor de cada varivel. Se o valor de apenas uma varivel no puder ser informado, ento nen- hum dos valores das outras variveis so retornados [Dav97]. As condies de erro que podem acontecer so : para uma varivel referenciada no campo variablebindings que no seja en- contrada uma correspondente na MIBemquesto; ou a varivel referenciada pode ser um tipo agregado e desta forma no h uma valor agregado a esta instncia. Neste caso, a entidade receptora retorna uma GetResponse PDU com o campo error-status indicando noSuchName e com o valor do campo error-index indicando que varivel da lista de variveis ( variablebindings) causou o problema, ou seja, se a terceira varivel da lista de variveis no estiver disponvel para a operao Get, ento o campo error-index da Ge- tResponse PDU possui o valor 3; a entidade receptora pode fornecer o valor de todas as variveis da lista, mas o tamanho resultante da GetResponse PDU pode exceder a limitao local. Neste caso, a entidade receptora envia entidade emissora uma Ge- tResponse PDU com o campo errorstatus indicando tooBig; a entidade receptora pode no fornecer o valor de uma determinada varivel por alguma outra razo. Neste caso, a entidade receptora retorna uma Ge- tResponse PDU com o campo error-status indicando genErr e com o valor do campo error-index indicando que varivel da lista de variveis causou o erro. Se nenhum dos casos anterior se aplica, ento a entidade receptora envia para a entidade da qual originou a GetRequest PDU uma GetResponse PDU com o campo errorstatus indicando noError e com o valor do campo error-index com valor zero. 4.7.2 GetNextRequest PDU A GetNextRequest PDU utilizada pela estao de gerncia SNMP para ex- ecutar a operao GetNext, requisitando ao agente SNMP a leitura da prxima varivel na ordem lexicogrca da MIB da mquina onde ele se encontra. A Get- NextRequest PDU praticamente idntica GetRequest PDU, possuindo o mesmo mecanismo de troca e a mesma estrutura, como mostrado na Figura 4.7. A nica diferena o seguinte: numa GetRequest PDU cada varivel descrita na lista de variveis ( variablebindings) deve ter seu valor retornado. Na Get- NextRequest PDU, para cada varivel, retornado o valor da instncia que a prxima na ordem segundo a denio da MIB. Assim como a GetRequest PDU, 55 Figura 4.7: Formato da GetNextRequest PDU a GetNextRequest PDU chamada ou todos os valores de todas as variveis da lista ( variablebindings) so retornados ou nenhum deles , conforme mostrado na gura 4.8. Figura 4.8: Passagem da GetNextRequest PDU Apesar de parecer pouco signicante, esta diferena entre a GetRequest PDU e a GetNextRequest PDU possui grandes implicaes. A m de entender essas implicaes vamos analisar algumas possibilidades: Supondo que uma estao de gerncia (NMS) deseje recuperar os valores de todas as variveis simples do grupo UDP de uma determinada MIB. A NMS ento envia ao gerente responsvel por gerenciar esta MIB uma GetRequest PDU na seguinte forma: Get Reques t ( udpI nDat agr ams . 0 , udpNoPor t s . 0 , udpI nEr r or s . 0 , udpOut Dat agr ams . 0 ) 56 Se a MIB em questo suportar todas as variveis relacionadas na lista, ento uma GetResponse PDU dever ser retornada com os respectivos valores das var- iveis referenciadas na GetRequest PDU: Get Response ( ( udpI ndat agr ams . 0 = 100) , ( udpNoPor t s . 0 = 1) , ( udpI nEr r or s . 0 = 2) , ( udpOut Dat agr ams . 0 = 200) ) Onde 100, 1, 2 e 200 so os valores das respectivas variveis requisitadas no GetRequest. Entretanto, se no for possvel retornar o valor de qualquer das variveis, ento a GetResponse PDU descartada e outra GetResponse PDU construda e enviada ao gerente da NMS com o cdigo de erro indicando no- SuchName. Para assegurar que todos os valores disponveis sejam informados, utilizando-se a GetRequest PDU, a estao de gerenciamento teria que enviar qua- tro destas PDU separadas, cada uma requisitando o valor de uma varivel espec- ca. Agora consideremos a utilizao da GetNextRequest PDU na recuperao dos valores das variveis: Get Next Reques t ( udpI ndat agr ams . 0 , udpNoPor t s . 0 , udpI nEr r or s . 0 , udpOut Dat agr ams . 0 ) Neste caso, o agente ir retornar o valor da prxima instncia do objeto (var- ivel) para cada identicador da lista de variveis. Suponha agora que todas as variveis da lista sejam suportadas pela MIB em questo. O identicador (Object Identier) para a varivel udpInErrors, por exemplo, 1.3.6.1.2.1.7.3. A prxima instncia para esta mesma varivel na ordem da MIB identicada por udpIn- Errors.0 ou 1.3.6.1.2.1.7.3.0. Da mesma forma, a prxima instncia de udpNo- Ports (1.3.6.1.2.1.7.2) udpNoPorts.0 (1.3.6.1.2.1.7.2.0), e assim para as outras variveis. Assim, se todos os valores esto disponveis, o agente ir retornar uma GetResponse PDU na seguinte forma: Get Response ( ( udpI ndat agr ams . 0 = 100) , ( udpNoPor t s . 0 = 1) , ( udpI nEr r or s . 0 = 2) , ( udpOut Dat agr ams . 0 = 200) ) A qual a mesma retornada com a utilizao da GetRequest PDU. Agora, suponhamos que o valor de udpNoPorts no esteja disponvel e que a mesma Get- NextRequest PDU seja utilizada. Neste caso, a resposta do agente viria na seguinte forma: Get Response ( ( udpI ndat agr ams . 0 = 100) , ( udpI nEr r or s . 0 = 2) , ( udpI nEr r or s . 0 = 2) , ( udpOut Dat agr ams . 0 = 200) ) 57 Neste caso, o identicador da varivel udpNoPorts.0 no um identicador vlido para a MIB em questo. Portanto, o agente retorna o valor da prxima instncia na ordem, a qual neste caso udpInErrors.0. Pode-se perceber que a utilizao da GetNextRequest PDU permite um melhor desempenho na recuperao de um conjunto de valores de variveis quando h a possibilidade de algum destes valores no estarem disponveis. A utilizao da operao GetNext particularmente interessante na recuper- ao de uma seqncia de instncias de variveis. No entanto, esta operao ainda possui o inconveniente de se ter que enviar sucessivas GetNextRequest PDU, pois este tipo de PDU no permite recuperar um nmero grande de instncias. 4.7.3 GetBulkRequest PDU A GetBulk PDU utilizada por um gerente SNMP para executar a operao GetBulk, uma das melhores caractersticas adicionadas ao SNMP padro, que permite que um gerente SNMP resgate uma grande quantidade de informaes de gerenciamento de uma determinada MIB. A GetBulkRequest PDU permite a um gerente SNMP requisitar que a resposta (GetResponse PDU) seja to grande quanto possvel dentro da restrio de tamanho. A GetBulkRequest PDU segue o mesmo princpio da GetNextRequest PDU, recuperando sempre a prxima instncia, na ordenao da MIB, de cada varivel da lista de variveis ( variablebindings). A diferena que, com a GetBulkRe- quest PDU, possvel especicar quantas prximas instncias na ordem devem ser retornadas na mesma GetResponse PDU. Figura 4.9: Formato da GetBulkRequest PDU Como mostrado na Figura 4.9, a GetBulkRequest PDU utiliza um formato diferente das demais PDU, com os seguintes campos: PDU type, request-id e variablesbindings - Estes campos possuem na Get- BulkRequest PDU a mesma funo que possuem nas demais PDU (GetRe- quest PDU, GetNextRequest PDU, SetRequest PDU, Response PDU, In- formRequest PDU e Trap PDU); 58 Nonrepeaters - Especica o total das primeiras variveis da lista de variveis ( variablebindings) das quais apenas a prxima instncia na ordem deve ser retornada; Max-repetitions - Especica o nmero de sucessores, tam- bm na ordem, que devem ser retornados para o resto (total_de_variveis_da_lista - Nonrepeaters) das variveis da lista de variveis. Aps executar a operao GetBulk o agente deve construir uma GetResponse PDU, contendo as instncias das variveis requisitadas e seus respectivos valores. No entanto, pode acontecer de a GetResponse PDU no retornar todos os pares (instncia, valor) requisitados na lista (podendo at retornar nenhum dos pares). Isso pode ocorrer por trs razes: 1. se o tamanho da mensagem que encapsula a GetResponse PDU exceder a limitao local de tamanho ou exceder o tamanho mximo de uma men- sagem de request (denido pelo protocolo), ento a GetResponse gerada com um nmero menor de pares no campo variablebindings. Ou seja, a Ge- tResponse PDU gerada inserindo-se os pares at que o tamanho mximo seja alcanado; 2. se todos os pares subseqentes descritos na lista de variveis possurem o valor endOfMibView (signicando que no existe um sucessor da varivel na ordem da MIB), o campo variablebindings pode ser truncado neste ponto, retornando nenhum dos pares requisitados; 3. se o processamento de uma GetBulkRequest PDU necessitar de uma grande quantidade de tempo de processamento pelo agente, ento o agente pode particionar o processamento, retornando resultados parciais. A gura 4.10 ilustra o funcionamento deste tipo de PDU. Se o processamento de alguma varivel falhar, por qualquer motivo que no seja endOfMibView, ento nenhum dos pares requisitados retornado. Em vez disso, o agente envia ao gerente uma GetResponse PDU com o campo error-status indicando genErr e o valor do campo error-index apontando para a varivel da lista que gerou o problema. O cdigo de erro tooBig nunca retornado por um agente SNMP pois, como j foi dito, quando a mensagem de resposta muito grande nem todas as variveis requisitadas so retornadas na mesma PDU, diminuindo seu tamanho. 59 Figura 4.10: Passagem da GetBulkRequest PDU 4.7.4 SetRequest PDU A SetRequest PDU utilizada por um gerente SNMP na realizao da oper- ao Set, indicando ao agente que o valor de determinada(s) varivel(is) deve(m) ser alterado(s). Este tipo de PDUpossui o mesmo formato da GetRequest PDU. No entanto, utilizada para escrever uma varivel na MIB, ao invs de l-la. Diferente da GetRequest PDU e da GetNextRequest PDU, cujo valor das variveis referen- ciadas na lista ( variablebindings) tm valor zero, neste tipo de PDU o valor de cada instncia da lista representa o valor a ser modicado na MIB em questo. Na gura 4.11 pode-se observar os campos de uma mensagem SetRequest PDU. Figura 4.11: Estrutura da SetRequest PDU Quando um agente recebe uma SetRequest PDU ele efetua, quando possvel, a operao Set, modicando o valor das variveis correspondentes, e retorna ao gerente da NMS emissora uma GetResponse PDU contendo o mesmo request-id. Assim como a operao Get, a operao Set solicitada ou todas as variveis so modicadas/atualizadas ou nenhuma delas o . Se um agente que recebeu uma SetRequest PDU puder alterar o valor de todas as variveis especicadas na lista ( variablebindings), ento ele constri uma Ge- tResponse PDU incluindo a mesma lista de variveis, com seus respectivos valores 60 atualizados, enviando-a ao gerente da NMS emissora. Se ao menos um dos valores no puder ser modicado, ento nenhum valor retornado e nem escrito na MIB em questo. As mesmas condies de erro usadas na GetRequest PDU podem ser retornadas (noSuchName, tooBig, genErr). Outro erro que pode ocorrer durante a operao Set o badValue. Esta condio de erro ocorre quando algum dos pares (varivel, valor) contidos na Se- tRequest PDU estiver inconsistente no que diz respeito ao tipo, tamanho ou valor. Quando algum erro ocorre o agente descarta a GetResponse PDU e constri uma nova com o campo statuserror indicando o tipo de erro que ocorreu durante a oper- ao e com o campo error-index apontando para a varivel da lista que ocasionou o problema. A gura 4.12 ilustra o funcionamento deste tipo de PDU. Figura 4.12: Passagem da SetRequest PDU Um curioso cdigo de erro que pode ser retornado por um agente durante a execuo da operao Set o read-only, que praticamente no implementado. O problema que o read-only signica que uma determinada varivel na MIB em questo cujo valor deveria ser modicado possui status de apenas leitura (read- only), no podendo portanto ser alterado. No entanto, quando um gerente pede a um agente para modicar uma varivel que seja do tipo read only, o agente no podendo executar esta operao, constri e envia uma GetResponse PDU com o cdigo de erro indicando noSuchName e no readOnly. O grande problema desta confuso o fato de que quando um gerente recebe uma GetResponse PDU de uma operao de Set com o cdigo de erro indicando noSuchName, ele no tem como saber se a instncia da varivel realmente no foi encontrada na MIB (o que justica o noSuchName) ou se o problema, na verdade, que a instncia da varivel possui status read only na MIB em questo. Neste caso, para ter certeza da origem do problema, o gerente teria que enviar uma GetRequest PDU para a varivel que causou o problema a m de vericar 61 se realmente a varivel no existe na MIB ou se ela apenas possui o status de read-only. 4.7.5 Trap PDU A Trap PDU utilizada pelo agente SNMP na execuo da operao Trap, noticando de forma assncrona eventos extraordinrios que tenham ocorrido no objeto gerenciado. A Trap PDU possui uma estrutura diferente das outras PDU como mostrada na Figura 4.13. Figura 4.13: Estrutura da Trap PDU - SNMP PDU type - indica o tipo de PDU, neste caso indica que trata-se de uma Trap PDU; enterprise - indica o tipo do objeto que gerou o Trap; este campo preenchido a partir do sysObjectID; agent-addr - endereo do objeto que gerou o Trap; generic-trap - indica o tipo do Trap; os valores possveis para este campo so: coldStart (0) - Signica que a entidade emissora do Trap est sendo inicializada, de tal modo que a congurao do agente ou da entidade de protocolo podem ser alteradas; warmStart (1) - Signica que a entidade emissora do Trap est sendo reinicializada, de tal modo que nenhuma congurao do agente nem da entidade alterada; linkDown (2) - Signica que a entidade emissora do Trap reconheceu que o estado de alguma de suas linhas de comunicao representadas na congurao do agente est disponvel; linkUp (3) - Signica que a entidade emissora do Trap reconheceu que o estado de uma de suas linhas de comunicao representadas na congurao do agente est disponvel; 62 authentication-Failure (4) - Signica que a entidade emissora do Trap foi o destinatrio de uma mensagem de protocolo que no estava corre- tamente autenticada. Quando da implementao do gerente, esta pro- priedade de enviar este tipo de Trap deve ser congurvel, podendo em determinados casos ser desativada; egpNeighborLoss (5) - Signica que um vizinho EGP (Exterior Gate- way Protocol) da entidade emissora do Trap foi o mesmo EGP de quem a entidade emissora marcou a queda e cujo relacionamento foi perdido; enterprise-Specic (6) - Signica que a entidade emissora do Trap re- conhece que ocorreu algum evento avanado especco ocorreu; specic-trap - possui o cdigo especco do Trap; time-stamp - armazena o tempo decorrido entre a ltima reinicializao da entidade que gerou o Trap e a gerao do Trap; contm o valor de sysUpTime; variablebindings - Uma lista de nomes de variveis e seus respectivos valores. Toda vez que uma mquina da rede inicializada, o agente responsvel deve enviar ao gerente um Trap do tipo coldStart (0), indicando que a mquina "en- trou"na rede. Outra caracterstica que difere a Trap PDU das outras PDU o fato de que ela no necessita de uma resposta, como mostra a Figura 4.14. Figura 4.14: Passagem da Trap PDU 4.7.6 Trap PDU-v2 A Trap PDU-v2 segue as mesmas regras da Trap PDU utilizada na verso bsica do SNMP, mas com um formato diferente. Conforme a Figura 4.15, este 63 formato o mesmo de todas as outras PDU utilizadas no SNMP, exceto a Get- BulkRequest PDU, o que facilita o processamento das mensagens pelo agente SNMP. Figura 4.15: Estrutura da Trap PDU - SNMPv2 4.7.7 InformRequest PDU A InformRequest PDU enviada por um agente SNMP a outro agente SNMP, fornecendo informaes de gerenciamento ao ltimo agente. Esta PDU inclui o campo variablebindings com os mesmos elementos da Trap PDU-v2, como mostra a Figura 4.16. Figura 4.16: Estrutura da InformRequest PDU Ao receber uma InformRequest PDU, o agente determina o tamanho da men- sagem de resposta que encapsula uma GetResponse PDU com os mesmos valores dos campos request-id, error-status, error-index e variablebindings da InformRe- quest PDU recebida. Se este tamanho exceder a limitao local de tamanho ou ex- ceder o tamanho mximo da mensagem de resposta, ento uma GetResponse PDU construda com o cdigo de erro (error-status) indicando tooBig, o ndice de erro (error-index) com valor zero e com a lista vazia de variveis ( variablebindings). A gura 4.17 ilustra o funcionamento deste tipo de PDU. Caso o tamanho da mensagem seja aceitvel, seu contedo passado para a aplicao destino e construda e enviada para o agente origem uma GetResponse PDU com o cdigo de erro indicando noError e o ndice de erro com valor zero. 4.7.8 GetResponse PDU O formato da GetResponse PDU idntico a GetRequest PDU a no ser pela indicao do tipo (PDU Type). Uma GetResponse PDU gerada por uma entidade SNMP sempre que esta recebe uma GetRequest PDU, GetNextRequest PDU ou SetRequestPDU, como descrito anteriormente. 64 Figura 4.17: Passagem da InformRequest PDU 4.8 Consideraes Finais Este captulo teve como objetivo realizar uma explanao sobre a origem, car- actersticas e o funcionamento do protocolo SNMP. Tambm realizou-se um es- tudo detalhado sobre os elementos e as operaes que podem ser executadas sobre as variveis MIBs, exibindo o formato para cada tipo de mensagem e o seu fun- cionamento, sempre procurando fornecer ao administrador de redes informaes que possibilite obter maturidade para a implementao de agentes SNMP em sua rede. 65 66 Captulo 5 Desenvolvimento de Agentes SNMP 5.1 Introduo Neste captulo ser tratado as formas e tcnicas necessrias ao desenvolvi- mento de agentes SNMP. O Desenvolvimento de agentes SNMP em Ambientes Linux possvel sob duas ticas de implementao. A implementao atravs de agentes extensveis e estendidos. Extensveis - Normalmente j implementam a MIB-II. Usam o SNMP dire- tamente. Possuem APIs de programao para outros agentes. Estendidos - Implementam normalmente complementos da MIB-II (objetos especcos). Usam o SNMP indiretamente do agente extensvel. Interage com um agente extensvel atravs de APIs de programao. Em geral, o agente extensvel deve implementar o SNMP, para que os agentes estendidos utilizem. A interao com os recursos ainda deve ser feita de forma proprietria. Um agente extensvel pode possuir vrios agentes estendidos, interagindo com recursos diferentes. Normalmente um agente extensvel fornecido pelo sistema operacional ou por bibliotecas especcas, que o caso do Linux. Alm do agente, tem-se tambm bibliotecas auxiliares para manipulao de estruturas do protocolo (SnmpAPI) Para a construo de agentes, pode-se utilizar basicamente trs tcnicas prin- cipais : 67 Construo direta via sockets Proxy SNMP para extenso indireta de agente Construo de agentes estendidos via API dos agentes extensveis Sockets Aloca-se a porta UDP 161 e recebe-se mensagens remotamente. A aplicao deve ser capaz de entender as mensagens que chegar, isto , deve implementar o protocolo SNMP. Depois das requisies, as respostas devem ser geradas tambm de acordo com o protocolo. A aplicao deve saber enviar traps diretamente utilizando a porta 160 remota do gerente associado. Normalmente, deve-se implementar a MIB-II, alm dos objetos de gerenciamento extras Proxy Sobrepe-se o agente local atravs de um novo agente. O novo agente imple- menta objetos extras, e chama o agente original para os objetos anteriores. Assim, neste caso, evita a implementao da MIB-II. Porm apresenta alguns problemas, tais como duas portas so usadas para se acessar alguns recursos, possiblidade de cascateamento de proxys e duplo mapeamento em plataformas de uma mesma mquina. Agente Estendido Neste caso, apenas uma porta usa SNMP no sistema, que a porta 161 do agente extensvel. Assim, agentes estendidos so chamados apenas quando necessrio, tendo-se vrios agentes estendidos associados a um mesmo agente ex- tensvel. 5.2 Desenvolvimento de agentes via NET-SNMP O NET-SNMP um conjunto de softwares que inclui: Um agente SNMP extensvel ; Um daemon receptor de traps; Ferramentas de gerncia, como por exemplo, tkmib; 68 Ferramentas de desenvolvimento, como a mais comumente utilizada, mib2c; Bibliotecas de desenvolvimento, em especial, snmpwalk; Para a instalao do Net-SNMP deve-se seguinte os seguintes passos: 1. Logar-se se como root no diretrio padro; 2. Fazer o download do pacote # net-snmp-5.2.1.tar.gz , que se pode obter http://www.net-snmp.org. 3. Descompactar o pacote # tar xvfz net-snmp-5.2.1.tar.gz 4. Deslocar-se para o diretrio descompactado # cd net-snmp-5.2.1 5. Vericar as opes de congurao # ./configure --help 6. Utilzando apenas #./configure se utlizar, por padro, SNMPv1. 7. Compilar o pacote # make 8. Instalar o pacote # make install Os comandos do Net-SNMP so copiados para os diretrios /usr/local/bin e /usr/local/sbin. Caso estes diretrios no es- tejam presentes na varivel de ambiente PATH, necessrios acrescent-los. Os arquivos MIB utilizados pelo gerente SNMP cam localizados no diretrio /usr/local/share/snmp/mibs. Enm, ao nal dos passos anteriores, observa-se que a estrutura de diretrios listada na gura 5.1 estar criada. 5.2.1 Congurao do Agente SNMP O agente Net-SNMP o executvel snmpd que se encontra no di- retrio /usr/local/sbin. O arquivo de congurao utilizado pelo Net-SNMP chamado snmpd.conf e deve estar presente no diretrio /usr/local/share/snmp. A princpio, os fontes do pacote vem acompan- hado de um arquivo de exemplo (EXAMPLE.conf) que deve ser adaptado de acordo com as necessidades do ambiente de rede. Inicialmente, pode-se copiar este arquivo de exemplo de congurao atravs de: #cp /usr/loca/share/snmp/docs/EXAMPLE.conf /usr/local/share/snmp/snmpd.conf Para mais informaes sobre arquivo de congurao, sugere-se consultar os manuais do arquivo 69 / r o o t / net snmp 5. 2. 1 / a ge nt # f o n t e s pa r a o daemon SNMP / mi bgr oup # f o n t e s pa r a as MIBs / mi bI I # f o n t e s da MIBI I / exampl es # f o n t e s de MIBs de exempl o / us r / bi n # f e r r a me n t a s snmp / s bi n # daemons snmpd e s nmpt r apd / l i b # b i b l i o t e c a s snmp / s ha r e / snmp / mi bs # a r q u i v o s de MIB em . t x t / snmpconf # a r q u i v o s de c o n f i g u r a c a o Figura 5.1: Estrutura de diretrio criada aps instalao Net-SNMP # man snmpd.conf Dentro desse arquivo, os campos mais signicantes so a declarao da mquina e o IP da rede que o agente SNMP ter acesso, local e a rede uti- lizada, para este caso ser simplesmente chamada minharede. Para efeito de exemplicao, a comunidade (community) tst: # s ec . name communi t y s our c e com2sec l o c a l l o c a l h o s t t s t com2sec mi nhar ede 1 9 2 . 9 . 2 0 1 . 0 / 2 4 t s t Em seguida, a declarao de grupos para acesso aos objetos SNMP gerencia- dos pelo agente SNMP, para local e minharede: # # Segundo passo , mapear os nomes s e gur os nos nomes dos gr upos : # s ec . model s ec . name gr oup l o c a l MeuGrupoRW v1 gr oup l o c a l MeuGrupoRW v2c gr oup MeuGrupoRO v1 mi nhar ede gr oup MeuGrupoRO v2c mi nhar ede Acesso de ler e esrever objetos MIB a partir de uma requisio local SNMP e acesso de somente leitura para requisies remotas: 70 # # Aqui 2 gr upos possuem a c e s s o de f or ma d i f e r e n t e # Pe r mi s s oe s de Es c r i t a : # c o n t e x t s ec . model s ec . l e v e l mat ch r e a d n o t i f Wr i t e a c c e s s e xa c t MyROGroup " " any noaut h a l l none none a c c e s s e xa c t MyRWGroup " " any noaut h a l l a l l none Em seguida, validao de traps SNMP TRAPs em direo ao gerente SNMP que est rodando na mquina local com a comunidade tst: # # Tr aps v1 e v2 h a b i l i t a s e p e r c e p t i v e i s na maqui na l o c a l # # command hos t t o manage communi t y t r a p s i n k l o c a l h o s t t s t t r a p 2 s i n k l o c a l h o s t t s t Pode-se tambm declarar os objetos sysLocation e sysContact para um sistema vazio: s y s l o c a t i o n Te r e s i na , Pi a ui , Br a s i l s y s c o n t a c t J Mes s i as <j me s s i a s @uf pi . br > Com a ferramenta snmpconf possivel gerar um arquivo snmpd.conf de uma forma interativa e fcil semsaber a sua estrutura. Para tanto, pode-se utiliz-lo de duas formas. Para uma criao rpida e simples de um arquivo snmpd.conf, utiliza-se: # snmpconf -g basic_setup Ou, ento, atravs de perguntas mais detalhistas, utilizando: # snmpconf Aps a criao do arquivo snmpd.conf, este deve ser copiado para o di- retrio /usr/local/share/snmp. Enm, pode-se iniciar o agente SNMP atravs de: # /etc/init.d/snmpd start Contactando o agente pela primeira vez. # snmpwalk localhost public system 71 Pode-se vericar a comunicao entre o agente e o gerente SNMP utilizando um sniffer de rede 1 , como tcpdump 2 , em uma outra janela ou terminal. # tcpdump -vv -i lo Para o correto funcionamento do Net-SNMP importante congurar as variaveis de ambiente do Linux. Para acessar todos os objetos MIB gerenciados pelo agente SNMP de uma forma simbolica e no numrica (OID), necessrio ler os arquivos MIB que esto contidos no diretrio /usr/local/share/snmp/mibs. # # PATH # PATH=$PATH: / us r / l o c a l / bi n : / us r / l o c a l / s bi n # MIBS: f o r c a l e r t odos os a r q ui v os MIB p r e s e n t e s # em / us r / l o c a l / s ha r e / snmp / mi bs # MIBS=ALL # e x p o r t a r t oda s as v a r i a v e i s # e xpor t PATH MIBS 1 Um sniffer um programa que consegue capturar todo o trfego que passa em um segmento de uma rede 2 TCPDump um poderoso analisador de pacotes de rede baseado em modo texto. Est disponvel em: http://www.tcpdump.org 72 Para a utilizao de todas as operaes existentes no protocolo SNMP, na tabela 5.1 tem-se um conjunto de comandos que se pode utilizar para realizar tais operaes. Tabela 5.1: Comandos do Net-SNMP COMANDO DESCRIO snmpget envia uma requisio SNMP Get para obter o valor atual contido em um objeto MIB gerenciado por um agente SNMP remoto. snmpset envia uma requisio SNMP Set para atualizar o valor atual contido em um objeto MIB gerenciado por um agente SNMP remoto. snmpgetnext envia uma requisio SNMP GetNext e obtm o valor do prximo objeto MIB gerenciado gerenciado por um agente SNMP remoto, se disponvel. snmpwalk este comando semelhante ao comando snmpgetnext, porm permiti obter todos os valores de uma MIB. snmptranslate permiti converter um objeto MIB representado sob a forma simblica para a forma decimal (OID) e vice-versa. A seguir, alguns exemplos de utilizao dos comandos listados na tabela 5.1. Correspondncia entre uma OID e sua forma simblica # s n mp t r a n s l a t e 1 . 3 . 6 . 1 . 2 . 1 . 1 . 3 . 0 SNMPv2MIB: : sysUpTime . 0 Representao grca de um sistema por meio da anlise dos arquivos MIB contidos no diretrio /usr/local/share/snmp/mibs: # s n mp t r a n s l a t e Tp IR s ys t em + s ys t em ( 1 ) | + R St r i n g s ys Des cr ( 1 ) | Te xt ua l Convent i on : Di s p l a y St r i n g | Si z e : 0 . . 2 5 5 . . . Requisio em SNMPv1 para obter o valor atual do objeto sysUpTime geren- ciado pelo agente SNMP executado na mquina local: # snmpget v 1 C t s t l o c a l h o s t s ys t em . sysUpTime . 0 SNMPv2MIB: : sysUpTime . 0 = Ti me t i c ks : ( 12908) 0 : 0 2 : 0 9 . 0 8 Requisio em SNMPv2c para obter o valor atual do objeto sysUpTime: 73 # snmpget v 2c C t s t l o c a l h o s t s ys t em . sysUpTime . 0 SNMPv2MIB: : sysUpTime . 0 = Ti me t i c ks : ( 13966) 0 : 0 2 : 1 9 . 6 6 Requisio em SNMPv1 para obter o valor atual dos objetos sysLocation e sysContact (denidos no arquivo snmpd.conf): # snmpget v 1 C t s t l o c a l h o s t s ys t em . s ys Loc a t i on . 0 SNMPv2MIB: : s ys Loc a t i on . 0 = STRING: Te r e s i na , Pi au , Br a s i l # snmpget v 1 C t s t l o c a l h o s t s ys t em . s ys Cont a c t . 0 SNMPv2MIB: : s ys Cont a c t . 0 = STRING: J Mes s i as <j me s s i a s @uf pi . br > Perguntando ao sistema por objetos MIB gerenciados pelo agente SNMP exe- cutado na mquina local: # snmpwalk v 1 C t s t l o c a l h o s t s ys t em SNMPv2MIB: : s ys Des cr . 0 = STRING: Li nux j or da n 2. 4. 18 3 #1 Mon Apr 11 07: 31: 07 EDT 2005 i 586 SNMPv2MIB: : s ys Obj e ct I D . 0 = OID: NetSNMPMIB: : net SnmpAgent OIDs SNMPv2MIB: : sysUpTime . 0 = Ti me t i c ks : ( 28119) 0 : 0 7 : 2 1 . 1 9 SNMPv2MIB: : s ys Cont a c t . 0 = STRING: J Mes s i as <j me s s i a s @uf pi . br > SNMPv2MIB: : sysName . 0 = STRING: j or da n SNMPv2MIB: : s ys Loc a t i on . 0 = STRING: Te r e s i na , Pi au , Br a s i l . . . Colocando um novo valor ao objeto sysLocation usando o SNMPv1: # snmpset v 1 C t s t l o c a l h o s t s ys t em . s ys Loc a t i on . 0 s " gaus s " Er r or i n pa c ke t . Reason : ( noSuchName ) Ther e i s v a r i a b l e No such name i n t h i s MIB. Fa i l e d o b j e c t : SNMPv2MIB: : s ys Loc a t i on . 0 Colocando um novo valor ao objeto sysLocation usando o SNMPv2c: # snmpset v 2c C t s t l o c a l h o s t s ys t em . s ys Loc a t i on . 0 S " gaus s " Er r or i n pa c ke t . Reason : n o t Wr i t a b l e ( t h a t o b j e c t does not s uppor t mo d i f i c a t i o n ) Fa i l e d o b j e c t : SNMPv2MIB: : s ys Loc a t i on . 0 Comparando as sadas dos dois ltimos comandos snmpset, pode-se perceber que o SNMPv1 no retorna um cdigo de erro, o que j acontece com o SNMPv2c. Neste caso, est-se tentando modicar um objeto MIB com acesso de somente leitura. 74 5.3 Escrevendo e Instalando uma nova MIB Nesta seo, mostrar-se- como escrever uma MIB exemplo e instala-l junto a um novo daemon snmpd. A MIB que ser utilizada de exemplo ser a exibida no anexo A1. Copiando a MIB para o diretrio de MIBS. # cp JM-TESTE-1-MIB.txt /usr/local/share/snmp/mibs Fazendo com que as ferramentas SNMP reconhea esta MIB. # echo "mibs +JM-TESTE-1-MIB" >> /usr/local/share/snmp/snmp.conf Para vericar se a MIB est carregada utiliza-se o comando snmptranslate: # snmptranslate -IR -Tp experimental 5.3.1 Gerando um esqueleto de cdigo C Pode-se utilizar a ferramenta mib2c para gerar um esqueleto de cdigo em C para suporte a uma nova MIB. O esqueleto de cdigo deve ser instrumentado pelo desenvolvedor, e compilado junto ao agente SNMP, gerando um novo daemon snmpd. A ferramenta mib2c encontrada em /usr/bin/mib2c Para executar, entretanto, ela necessita de suporte SNMP via Perl Para instalar suporte SNMP via Perl: # cd / r oot / net snmp 5. 2. 1/ p e r l / SNMP # p e r l Mak e f i l e . PL NETSNMPPATH=/ us r # make # make t e s t # make i n s t a l l Figura 5.2: Passos para instalar no Net-SNMP suporte a Perl Supondo um arquivo de MIB chamado JM-TESTE-1-MIB.txt que inter- namente dene um mdulo jmteste 1. Copiar o arquivo de MIB para o diretrio de arquivos de MIB # cp JM-TESTE-1-MIB.txt /usr usr/share/snmp/mibs # chmod 755 JM-TESTE-1-MIB.txt 75 necessrio que as ferramentas do Net-SNMP reconhea esta nova MIB. Para tanto, deve-se executar o seguinte comando: # echo "mibs +JM-TESTE-1-MIB" >> /usr/local/share/snmp/snmp.conf 2. Exportar todas as MIBs as - # export MIBS=ALL 3. Ir para o diretrio de desenvolvimento de agente - # cd /root/net-snmp-5.2.1/agent/mibgroup/examples 4. Compilar o arquivo de MIB via mib2c - # /usr/bin/mib2c JM-TESTE-1-MIB 5.3.2 Congurando a compilao de um novo daemon snmpd Aps usar o mib2c, dois arquivos devem ter sido no seu diretrio criados, JM-TESTE-1-MIB.c e JM-TESTE-1-MIB.h . Para no misturar com o exemplo anterior, iremos renome-los simplemente para exemplo.c e exemplo.h. Depois de instrumentar o arquivo exemplo.c, necessrio congurar a compi- lao de um novo daemon snmpd com suporte a exemplo, conforme os passos a seguir. 1. Ir para o diretrio de instalao do NET-SNMP # cd /root/net-snmp-5.2.1/perl/SNMP 2. Gerar nova congurao incluindo exemplo # ./configure --prefix=/usr --with-mib modules="examples/exemplo" 5.3.3 Compilando e instalando o suporte a MIB exemplo 1. Interromper o daemon snmpd (se em execuo ) - # /etc/init.d/snmpd stop 2. Ir para o diretrio de compilao do daemon snmpd - # cd /root/net-snmp-5.2.1/agent 76 3. Compilar o novo daemon - # make 4. Instalar o novo daemon - # make install 5. Inicializar o novo daemon - # /etc/init.d/snmpd start 6. Testar se o agente responde MIB exemplo # snmpwalk localhost public exemplo ! Na gura 5.3 tem-se os diretrios utilizados com Net-SNMP e a descrio de cada um. # Di r e t o r i o para col ocacao de novas MIBs / us r / s ha r e / snmp / mi bs # Di r e t o r i o para c onf i gur ac ao do novo agent e snmp / r o o t / net snmp 5. 2. 1 # Di r e t o r i o para os f o n t e s do age nt e a s e r c o n s t r u i d o / r o o t / net snmp 5. 2. 1/ a ge nt / mi bgr oup / exampl es / # Di r e t o r i o para compi l acao e i n s t a l a c a o do novo daemon snmp / r o o t / net snmp 5. 2. 1/ a ge nt # Di r e t o r i o de c o n t r o l e do daemon snmpd / e t c / i n i t . d / snmpd Figura 5.3: Resumo dos diretrios utilizados com Net-SNMP Sugeri-se sempre utilizar trs shells no processo de desenvolvimento de su- porte a MIBs, como a MIB JM-TESTE-1-MIB: 1. Shell para edio do fonte exemplo.c # cd /root/net-snmp-5.2.1/agent/mibgroup/examples 77 2. Shell para edio da MIB JM-TESTE-1-MIB.txt # cd /usr/share/snmp/mibs 3. Shell para compilao, instalao e execuo do daemon snmp # cd /root/net-snmp-5.2.1/agent # ln -s /etc/init.d/snmpd snmpdd Instrumentao do cdigo O cdigo gerado por mib2c no livre de erros. Geralmente, apresenta dois principais problemas , a princpio, devem ser resolvidos: Correo das rotinas de escrita em Strings (e derivados, por exemplo en- dereos IP) Denio do nmero de linhas de uma tabela atravs da constante TABLE_SIZE Correo das rotinas de em Strings (e derivados ) O cdigo original abaixo abaixo: cas e RESERVE2: s i z e = var _ v a l _ l e n ; s t r i n g = ( char char ) va r _ va l ; Deve ser substitudo por: cas e RESERVE2: s i z e = var _ v a l _ l e n ; s t r n c p y ( s t r i n g , ( char char ) va r _ va l val , s i z e ) ; s t r i n g [ s i z e ] = 0; Denio do nmero de linhas de uma tabela atravs da constante TABLE_SIZE O cdigo : i f ( h e a d e r _ s i mp l e _ t a b l e ( vp , name , l e ngt h , exact , va r _ l e n , wr i t e_met hod , TABLE_SIZE) == MATCH_FAILED ) Deve ser substitudo por: i f ( h e a d e r _ s i mp l e _ t a b l e ( vp , name , l e ngt h , exact , var _l en , wr i t e_met hod , 3) == MATCH_FAILED ) Onde 3 o nmero de linhas da tabela 78 5.3.4 Traps em NET-SNMP H trs funes que so utilizadas para o envio de traps de dentro de um m- dulo snmpd. So elas: send_easy_trap send_trap_vars send_v2trap As traps so enviadas para todos os gerentes cadastrado no arquivo de cong- urao snmpd.conf A funo send_easy_trap usada para enviar traps rapidamente, sem a passagem de objetos extras (alm do sysUpTime conven- cional de uma trap). A funo send_var_traps usada para enviar traps, mas com a possibilidade de se ter objetos extras (alm do sysUpTime). A funo send_v2trap usada para enviar traps SNMPv2. 5.4 Consideraes Finais A ferramenta descrita neste captulo possui vrias caractersticas que possibili- tam a real implementao de agentes SNMP em ambientes Linux. Explanou-se sobre a congurao e instalao dessa ferramenta, a estrutura de diretrios uti- lizadas por ela, os comandos que realizam as operanes do protocolo SNMP e utilizao da mib2c, para a criao de esqueletos de cdigo C a partir de MIBs. No Captulo 6 apresentado ferramentas para a visualizao dos dados existentes nas MIBs instaladas, atravs de grcos, sua instalao e congurao. 79 80 Captulo 6 Monitoramento e Visualizao atravs do MRTG 6.1 Introduo MRTG (Multi Router Trafc Grapher) uma ferramenta de monitoramento, um pacote escrito em Perl usado para controlar o trfego e os recursos de rede. Com o MRTG possvel realizar a monitorao de qualquer equipamento que oferea suporte ao protocolo SNMP. Seu relatrio relado em formato HTML, sendo assim, podendo ser publicado atravs de um servidor de HTTP (Web). 6.2 Download e Instalao 6.2.1 Download Pode-se baixar o MRTG a partir da URL: http://people.ee.ethz.ch/oetiker/webtools/mrtg/pub/mrtg.tar.gz. Recomenda-se a vericao de novas verses no site ocial, periodicamente. 81 6.2.2 Compilao e Instalao Acessando um diretrio temporrio de produo. # cd / us r / l o c a l / s r c # t a r x v f z mrt g 2. 10. 11. t a r . gz # cd mrt g 2. 10. 11 # . / c o n f i g u r e p r e f i x =/ us r / l o c a l / mrt g2 # make # make i n s t a l l Figura 6.1: Passos para compilao e instalao do MRTG 6.2.3 Congurando o MRTG Aps a instalao dos pacotes, partira-se- para a criao dos arquivos de con- gurao dos hosts que o MRTG ir monitorar. Para congurar o MRTG, preciso inicialmente duas aes: Congurar um arquivo com informaes sobre o dispositivo; Congurar um Agendador de Tarefa para reconhecer as informaes do dis- positivo. OMRTGpossui umutilitrio que auxilia na criao dos arquivos congurao. Trata-se do cfgmaker, que possui a seguinte sintaxe: # cfgmaker --output /etc/mrtg/disp_abc_xyz.cfg community@disp.abc.xyz Onde: o parmetro output dene o arquivo de congurao que ser gerado pelo cfgmaker; community a comunidade SNMP do host, que router.abc.xyz. Convm observar que para que o nome do host seja resolvido, o equipamento com o MRTG deve estar congurado com o(s) nome(s) do(s) servidor(es) DNS (arquivo /etc/resolv.conf); alm disso, necessrio registro no servidor DNS para o host, associando-o com o respectivo endereo IP. Tambm pode ser 82 utilizada uma entrada para o mesmo no arquivo /etc/hosts ou, ainda, o en- dereo IP no lugar do nome. Para exemplicar, supe-se que se tem uma placa de rede Ethernet 3COM 3C905C TX/TX-M Tornado com endereo IP 192.168.1.2 e comunidade SNMP public. A sintaxe do comando cfgmaker seria: # cfgmaker --output /etc/mrtg/eth0_3c905c.cfg public@192.168.1.2 Ser gerado o arquivo eth0_3c905c.cfg como sada (em /etc/mrtg). Este arquivo contm as informaes necessrias para que sejam gerados os gr- cos. Porm, existemalguns parmetros que podemser congurados no arquivo para melhor visualizao. Estes parmetros so denidos nas sees Global Cong Options e Global Defaults e alguns dele esto presente na tabela 6.1. Tabela 6.1: Opes de Congurao do MRTG OPO DESCRIO WorkDir:var/www/mrtg Dene qual ser a pasta de trabalho do MRTG, ou seja, a pasta onde sero salvos os arquivos gerados pelo MRTG (logs, arquivos html e png, etc). recomendvel criar uma sub-pasta para cada host. Options [_ ]: growright, bits So duas opes em uma (mas podem ser conguradas separadamente). O growright faz com que o grco desloque da direita para a esquerda, fazendo com que o horrio atual que direita no grco; j o parmetro bits dene que o grco trar as informaes em bits (por padro, as informaes so expressas em bytes). Refresh: 600 o tempo, em segundos, em que o navegador ir atualizar a pgina. Por padro, 300 segundos (5 minutos). Interval: 10 o tempo, em minutos, em que o MRTG ir buscar novas informaes estatsticas junto aohost. Por padro, 5 minutos. Language: brazilian Linguagem que ser utilizada nos arquivos HTML que o MRTG gera. RunAsDaemon: Yes Para rodar o MRTG como daemon processo. Ou seja, o MRTG car carregado, e vai buscar os dados do host conforme o parmetro Interval (ou nos 5 minutos padro). 83 6.2.4 Agendando Tarefa para o MRTG Pode-se programar o agendador de tarefa para executar o MRTG de tempos em tempos. Atualmente o padro de 5 minutos, mas como este processo est local, voc pode diminuir esse tempo para 3 min ou at mesmo 1 min. # crontab -e */5 * * * * /usr/bin/mrtg /home/mrtg/mrtg.conf 6.2.5 Execuo Com o arquivo (ou arquivos) de congurao pronto, hora de colocar o MRTG para monitorar os seus hosts. Isso relativamente fcil. No prompt, basta entrar com o comando: # mrtg /etc/mrtg/eth0_3c905c.cfg Essa linha de comando iniciar o MRTG como root. Se utilizou-se a opo RunAsDaemon, no necessrio acrescentar mais nada. Porm, ser necessrio digitar esta linha de comando sempre que a mquina for reinicializada. Alm disso, ser necessrio digitar uma linha de comando para cada arquivo de congurao (caso tenha optado por criar um arquivo por host, com eu fao). Para automatizar a tarefa, pode-se criar um script de inicializao, adicion-lo ao /etc/init.d e criar os links simblicos para os runlevels que sero utilizados. Tambm recomendvel a criao de um usurio para rodar o MRTG. Na gura 6.2 pode observar um script para inicializao do MRTG. # ! / bi n / sh / us r / bi n / mr t g us e r =mrt gus e r / e t c / mr t g / et h0_3c905c . cf g Figura 6.2: Exemplo de script para iniciar MRTG Convm lembrar que deve ser adicionada uma linha para cada arquivo CFG, se forem arquivos separados por hosts. Uma vez criado o script em /etc/init.d (que se sugere nomear mrtgd), tambm necessrio criar os links para os run- levels apropriados: # ln -s /etc/init.d/mrtgd /etc/rc3.d/S99mrtgd 84 Se forem exibidas mensagens de erro na criao de alguns arquivos, deve- se vericar as permisses nos diretrios /etc/mrtg (caso tenha sido criado) e /var/lock/mrtg. Recomenda-se, ainda, que seja atribuda propriedade destes diretrios ao usurio mrtg-user. 6.3 Visualizao de Relatrios O MRTG cria um arquivo HTML referente ao dispositivo em questo. O relatrio pode ser visto atravs de qualquer navegador (cliente HTTP). Normal- mente, o mesmo publicado atravs de um servidor HTTP, com acesso pblico ou privado. Pode-se observar nas guras 6.3 e 6.4, exemplos de relatrios gerados pelo MRTG para interface de rede. Figura 6.3: Exemplo de relatrio dirio gerado pela interface eth0 - 3com 85 Figura 6.4: Exemplo de relatrio anual gerado pela interface eth0 - 3com 6.4 Outras Ferramentas H vrias outras ferramentas que se destinam a visualizao de dados sememl- hantes ao MRTG. Entre elas se destaca o RRDTOOL uma ferramenta GPL escrita por Tobias Oetiker, o mesmo desenvolvedor do MRTG. Na realidade, o RRDtool 1 uma reimplementao do MRTG, desenvolvida para sobrepor uma srie de limitaes que o MRTG possui, permitindo se criar grcos e loggings de maneira rpida e exvel. O grande segredo do RRDtool est em sua base de dados, chamada RRD (Round Robin Database ) que permite criar grcos com qualquer tipo de dados. Dentre as caractersticas, ou melhor, vantagens que o RRDTool oferece, destaca-se: Banco de Dados Imutvel (tamanho) Possui Mdulo Perl para integrao com interfaces Web 1 Disponvel em http://www.rrdtool.org, ou diretamente em http://people.ee.ethz.ch/ oetik- er/webtools/rrdtool/pub/?M=D 86 Grcos totalmente personalizaveis Pode-se trabalhar com condicionais (IF, ELSE, LT, GT, EQ, entre outros) Permite utilizao de operadores (+, -, *, /, %) Pode-se utilizar funes matemticas(COS, EXP, LOG, entre outros) No foi possvel utilizar esta ferramnta neste trabalho, o que se far em tra- balhos futuros. No entanto, na gura 6.5 pode observar um grco gerado pelo RRDTool Figura 6.5: Exemplo de Grco gerado pelo RRDTool a partir de Roteador 6.5 Consideraes Finais A ferramentas descrita neste captulo oferece um boa visualizao que possi- bilita tirar concluses acerca do estado dos equipamentos presentes na rede. Pode- se gerar vrios tipos de grcos e preparar pginas de acordo com a necessidade de cada ambiente. 87 88 Captulo 7 Concluses O gerenciamento de rede um requerimento para qualquer administrador de redes que deseja controlar suas LANs e WANs. Esse novo e vasto imprio de produtos, projetados para atuar como sistemas cohesivos e bem organizados, pode rapidamente se tornar uma massa desorganizada de dispositivos operacionais in- dependentes. Para aliviar esses problemas, aplicaes de monitoramento de redes baseadas em SNMP devem ser empregadas. O gerenciamento de rede por meio de um sistema baseado em SNMP oferece diversas vises da rede, incluindo uma per- spectiva global, uma perspectiva de segmento e uma perspectiva do dispositivo. Tambm, o gerenciador de rede fornece uma rpida viso de problemas o que possibilita ao administrador a habilidade de ver problemas com uma simples veri- cao nos estados dos equipamentos atravs de grcos gerados por ferramentas. A necessidade de gerenciamento de redes evidente e tende a crescer medida que as redes se tornam maiores e mais complexas. Como essas redes esto cada vez mais heterogneas, uma padronizao do protocolo de gerncia garante que estas sejam gerenciadas de maneira uniforme. De maneira semelhante, com o crescimento na utilizao de equipamentos mveis, redes sem infra-estrutura e equipamentos domsticos em rede os proto- colos de gerencia precisaram sofrer simplicaes em funo da carncia de pro- cessamento e memria RAMdisponveis nesses equipamentos. Quando os equipa- mentos domsticos estiverem sendo usados ser necessria uma preocupao com a segurana no que tange: acesso, autenticao e aes de controle nesses equipa- mentos. 89 7.1 Pontos Positivos e Negativos do SNMP O SNMP tem vrios pontos positivos. Um deles sua popularidade para a gerncia de redes TCP/IP. Agentes SNMP esto disponveis para vrios disposi- tivos de rede, desde computadores at bridges, modems ou impressoras. Adicionalmente, o SNMP um protocolo de gerenciamento exvel e exten- svel. Pode-se estender os agentes SNMP para cobrir dados especcos de dispos- itivos, pelo uso de arquivos ASN.1. O SNMP pode assumir numerosos trabalhos especcos para classes de dispositivos fornecendo um mecanismo padro de con- trole de rede e monitoramento. Apesar de seu nome, (Simple Network Management Protocol), o SNMP um protocolo relativamente complexo para implementar. Tambm, o SNMP no um protocolo to eciente assim. Os modos nos quais so identicadas as variveis SNMP (como strings de byte onde cada byte corresponde a um nodo particular no banco de dados da MIB) conduz desnecessariamente a grandes pacotes de dados PDU, que consomem partes signicativas de cada mensagem de SNMP, sobrecar- regando a rede de transmisso de dados. Enquanto codicaes complicadas frustram programadores, a utilizao por parte dos usurios nais no dependem da complexidade dos algoritmos que disponibilizam os dados a eles. 7.2 Vantagens ao se utilizar SNMP Uma das principais vantagens do protocolo SNMP semdvida a sua simplici- dade, podendo ser facilmente implementado numa rede de computadores. Muitos dispositivos j vem de fbrica preparados para o uso do SNMP, sendo fcil a con- gurao dos agentes na rede. Alm disso, possvel tambm que um gerente de redes programe as variveis que deseja monitorar, tornando a rede exvel administrao do gerente. Tam- bm devido simplicidade, a maioria dos dispositivos existentes, mesmo os com baixo poder de processamento, podem utilizar o SNMP j que a concentrao do processamento ocorre na mquina do gerente. A rapidez uma caracterstica do SNMP, pois o gerente no precisa fazer um login no agente e estabelecer uma conexo TP/IP para receber seus dados. Outra vantagem do protocolo a sua popularidade. Isso pode ser identicado pelo fato de que a maioria dos fabricantes de dispositivos para redes os projetam para suportar SNMP, inclusive projetando mibs privadas com objetos particulares de cada dispositivo. 90 Outro benefcio do SNMP a expansibilidade. Por causa de seu projeto sim- ples, fcil para o protocolo ser atualizado de forma que ele possa ser adequado s necessidades de usurios no futuro. 7.3 Algumas limitaes do SNMPv1 OSNMP possui falhas no quesito segurana. Intrusos na rede podemter acesso a informaes dos dispositivos, alm de podem modicar as variveis dos mesmos alterando o funcionamento da rede. Portanto, o SNMP: No apropriado para o gerenciamento de redes muito grandes, devido a limitao de performance de pooling; Traps SNMP no so reconhecidos; O padro SMNP bsico prov somente autenticao trivial; O modelo SNMP MIB limitado e no suporta aplicaes que questionam o gerenciamento, baseadas em valores ou tipos de objetos; No suporta comunicao manager-to-manager. 7.4 O Futuro do SNMP (SNMPv3) O Grupo de Trabalho do SNMP verso 3 est encarregado de preparar as re- comendaes para a prxima gerao do SNMP. Oobjetivo deste grupo de trabalho a de produzir documentos necessrios para prover um padro para a prxima ger- ao de funes SNMP. Ao longo dos ltimos anos, vericou-se um grande nmero de atividades obje- tivando incorporar segurana e outros melhoramentos ao SNMP. Infelizmente no houve uma padronizao da evoluo da verso 2 devido a falta de incorporao dos melhoramentos criando-se assim duas verses que foram chamadas de V2u e V2*. O grupo de trabalho da verso 3 est trabalhando em novos conceitos baseados nestas duas verses divergentes, para que passe a existir uma documentao nica com elementos tcnicos incorporado das duas verses. O SNMPv3 que tem como objetivo principal alcanar a segurana, sem esquecer-se da simplicidade do protocolo, atravs de novas funcionalidades: autenticao e privacidade 91 autorizao e controle de acesso nomes de entidades pessoas e polticas usernames e gerncia de chaves destinos de noticaes relacionamentos proxy congurao remota O SNMPv3 trouxe como principais vantagens aspectos ligados segurana. Esta segurana busca evitar a alterao das mensagens enviadas. Almdisto, barra- se o acesso a elementos estranhos execuo de operaes de controle, que so realizadas atravs da primitiva SetRequest. Evita-se tambm a leitura das men- sagens por parte de estranhos, alm de se garantir ao gerente o direito de alterao da senha dos agentes. A segurana conseguida atravs da introduo de mecan- ismos de criptograa com o DES (Data Encryption Standard) e de algoritmos de autenticao que podem ser tanto o MD5 (Message Digest Algorithm 5) quanto o SHA (Secure Hash Algorithm). Contudo, o SNMPv3 ainda no prev a proteo contra Denial of Service, que impede a troca de informaes entre agente e gerente e contra Anlise de trfego, que permite a observao do padro geral do trfego entre agente e gerente. 7.5 Segurana no Protocolo SNMP O protocolo SNMP pode realizar operaes de recongurao na rede al- terando caractersticas de equipamentos ou at desligando mquinas, sendo que no existe qualquer mecanismo de segurana aplicado ao contedo das mensagens. O controle feito atravs da vericao do contedo de um campo especial no pacote do SNMP denominada comunidade. A comunidade denida como sendo o relacionamento entre duas entidades do SNMP. Ela denida como um conjunto de bytes formando caracteres ASCII que sero utilizados para efetuar este relacionamento. Dessa forma, quando realizada a comunicao entre duas entidades do SNMP, a entidade destinatria da mensagem realiza a vericao do contedo da comunidade para averiguar se esta informao proveniente do remetente indi- cado. 92 Atravs da comunidade possvel que o agente realize uma vericao da in- tegridade do agente realizando autenticao e polticas de acesso (agente controla que diferentes gerentes podem obter diferentes variveis da MIB) atravs deste campo. O mais importante no entendimento de comunidade, que sem o conhec- imento prvio da comunidade de um determinado equipamento gerencivel, ser impossvel a qualquer aplicao de gerncia acessar as informaes da MIB. Outra considerao importante que um equipamento pode ter mais de uma comunidade congurada, como uma com direitos de leitura, escrita e trap. Por- tanto, um mesmo equipamento poder contar com trs strings de comunidade diferentes. Isto tem o objetivo de se aumentar a segurana no acesso aos equipa- mentos. Por exemplo, o arquivo snmpd.conf onde se pode congurar o acesso que se quer fornecer s estaes gerente quando realizam a requisio SNMP. Pode-se limitar o acesso com read-only e read-write. Enm, com esse tipo de autenticao, o acesso a MIB se torna pouco seguro, devido principalmente a: Identicao da origem - a comunidade transmitida sem qualquer pro- teo Integridade da mensagem - ao ser interceptada a mensagem no garante qualquer proteo referente ao contedo Tempo-limite - perodo de tempo que a mensagem pode car presa por algum servio Privacidade - qualquer servio pode monitorar uma comunicao entre en- tidades SNMP Autorizao - no h controle de autorizao de acesso aos dados da MIB 7.6 Resultados Alcanados e Contribuies Dentro dos objetivos pretendidos por este trabalho, os estudos realizados pos- sibilitaram obter uma grande comprenso acerca de gerenciamento de redes, com- ponentes, solues, entre outras coisas. Tambm, mostrou como possvel e fcil escrever MIBs e desenvolver agentes SNMP com o uso de software livre, que esto a cada dia mais ecientes. Mostrou-se como o gerenciamento de redes com uso de SNMP em redes TCP/IP torna o trabalho do Administrador de Redes menos fatigante e mais agradvel. Pretendia-se experimentar mais outras ferramentas que auxiliam a construo de agentes e o monitoramento de redes. Contudo, adiou-se esta atividade para trabalhos posteriores. 93 7.7 Trabalhos Futuros Como futuros estudos, pretende-se aprofundar o estudo das ferramentas utilzadas neste Trabalho e experimentar mais ferramentas, tais como RRDTool, Nagios entre outras e realizar estudo comparativo de desempenho e funcionalidade entre elas. Deseja-se tambm fazer um estudo detalhado sobre CMIP, buscando observar semelhanas e diferenas com este outro protocolo. Por m, elaborar um artigo sobre Gerenciamento de Redes com Softwares Livres e Desenvolvimento de uma ferramenta para interpretao de dados e grcos. 94 Referncias Bibliogrcas [And04] TANENBAUM Andrew. Redes de Computadores. Editora Campus, Santa Clara, 4a. edition, 2004. [Dav] GUERRERO David. Network Management and Monitoring with Linux. Disponvel em http://www.develnet.es/ david/papers/snmp/. ltimo Acesso: 25 de Janeiro de 2005. [Dav97] PERKINS David. Understanding SNMP MIBs. California Evan McGin- nis, Santa Clara, 1997. [DW] STEVENSON Douglas W. Net Management: what it is and what it isnt. Disponvel em http://www.sce.carleton.ca/netmanage/NetMngmnt/NetMngmnt.html. ltimo Acesso: 25 de Janeiro de 2005. [Inc] Anixter Inc. An Introduction to SNMP. Disponvel em http://www.anixter.com/techlib/buying/network/snmp1.htm. ltimo Acesso: 25 de Janeiro de 2005. [RM01] SCHMIDT R. Mauro, DOUGLAS e Kevin J. SNMP Essencial. Campus, 2001. [Tel] DPS Telecom. SNMP Tutorial Series: 5 Quick Steps to Understand- ing SNMP and its Role in Network Alarm Monitoring. Disponvel em http://www.dpstele.com/layers/l2/snmp-tutorials.html. ltimo Acesso: 25 de Janeiro de 2005. [Wil96] STALLINGS Willian. SNMP, SNMPv2 and RMON. Addison Wesley, 2a. edition, 1996. [Yor] COHEN Yoran. SNMP simple network manage- ment protocol. Atualizao 02/2000. Disponvel em 95 http://wwwdos.uniinc.msk.ru/tech1/1995/snmp/snmp.htm. ltimo Acesso: 12 de Janeiro de 2005. 96 Apndice A Anexos A.1 Modelo de MIB para Utilizao Nesta MIB, denominada JM-TESTE-1-MIB, tem-se a utilizao de mdulos para agrupar objetos. No entanto, para simplicar o exemplo, criou-se apenas o objeto rstKey. JM-TESTE-1-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, INTEGER FROM SNMPv2-SMI; jmteste MODULE-IDENTITY LAST-UPDATED "200503040000Z" ORGANIZATION "DM-UFPI" CONTACT-INFO "None yet." DESCRIPTION "AgentX testing MIB" REVISION "200503040000Z" DESCRIPTION "None yet." ::= { experimental 72} firstKey OBJECT-TYPE SYNTAX INTEGER (0..100) MAX-ACCESS read-write STATUS current DESCRIPTION "Value initialized to 0 and on each access: - Return current val. - increment" 97 ::= { jmteste 1 } END A.2 Modelo de MIB em C e o seu Cabealho Tem-se aqui o cdigo de um arquivo em C gerado a partir do exemplo ini- cial deste apndice. Assim, tambm pode-se construir MIBs a partir cdigo em linguagem C. /* * Template MIB group implementation generated by mib2c - exemplo.c * */ /* include important headers */ #include <net-snmp/net-snmp-config.h> #if HAVE_STDLIB_H #include <stdlib.h> #endif #if HAVE_STRING_H #include <string.h> #else #include <strings.h> #endif /* needed by util_funcs.h */ #if TIME_WITH_SYS_TIME # ifdef WIN32 # include <sys/timeb.h> # else # include <sys/time.h> # endif # include <time.h> #else # if HAVE_SYS_TIME_H # include <sys/time.h> # else # include <time.h> # endif #endif #if HAVE_WINSOCK_H #include <winsock.h> #endif #if HAVE_NETINET_IN_H #include <netinet/in.h> #endif #include <net-snmp/net-snmp-includes.h> #include <net-snmp/agent/net-snmp-agent-includes.h> 98 /* header_generic() comes from here */ #include "util_funcs.h" /* include our .h file */ #include "example1.h" #include<net-snmp/library/snmp_debug.h> long firstKey = 0; /********************* * * Initialisation & common implementation functions * *********************/ /* * This array structure defines a representation of the * MIB being implemented. * * The type of the array is struct variableN, where N is * large enough to contain the longest OID sub-component * being loaded. This will normally be the maximum value * of the fifth field in each line. In this case, the second * and third entries are both of size 2, so were using * struct variable2 * * The supported values for N are listed in <agent/var_struct.h> * If the value you need is not listed there, simply use the * next largest that is. * * The format of each line is as follows * (using the first entry as an example): * 1: EXAMPLESTRING: * The magic number defined in the example header file. * This is passed to the callback routine and is used * to determine which object is being queried. * 2: ASN_OCTET_STR: * The type of the object. * Valid types are listed in <snmp_impl.h> * 3: RONLY (or RWRITE): * Whether this object can be SET or not. * 4: var_example: * The callback routine, used when the object is queried. * This will usually be the same for all objects in a module * and is typically defined later in this file. * 5: 1: * The length of the OID sub-component (the next field) * 6: {1}: * The OID sub-components of this entry. * In other words, the bits of the full OID that differ * between the various entries of this array. * This value is appended to the common prefix (defined later) * to obtain the full OID of each entry. 99 */ struct variable2 example_variables[] = { { EXAMPLEINTEGER, ASN_INTEGER, RWRITE, var_example, 1, {1}} }; /* * This array defines the OID of the top of the mib tree that were * registering underneath. * Note that this needs to be the correct size for the OID being * registered, so that the length of the OID can be calculated. * The format given here is the simplest way to achieve this. */ oid example_variables_oid[] = { 1,3,6,1,3,72 }; /* * This function is called at the time the agent starts up * to do any initializations that might be required. * * In theory it is optional and can be omitted if no * initialization is needed. In practise, every module * will need to register itself (or the objects being * implemented will not appear in the MIB tree), and this * registration is typically done here. * * If this function is added or removed, you must re-run * the configure script, to detect this change. */ void init_example2(void) { /* * Register ourselves with the agent to handle our mib tree. * The arguments are: * descr: A short description of the mib group being loaded. * var: The variable structure to load. * (the name of the variable structure defined above) * vartype: The type of this variable structure * theoid: The OID pointer this MIB is being registered underneath. */ REGISTER_MIB("example2", example_variables, variable2, example_variables_oid); } /* * Define the callback function used in the example_variables structure. * This is called whenever an incoming request refers to an object * within this sub-tree. * * Four of the parameters are used to pass information in. * These are: * vp The entry from the example_variables array for the * object being queried. * name The OID from the request. 100 * length The length of this OID. * exact A flag to indicate whether this is an exact request * (GET/SET) or an inexact one (GETNEXT/GETBULK). * * Four of the parameters are used to pass information back out. * These are: * name The OID being returned. * length The length of this OID. * var_len The length of the answer being returned. * write_method A pointer to the SET function for this object. * * Note that name & length serve a dual purpose in both roles. */ u_char * var_example(struct variable *vp, oid *name, size_t *length, int exact, size_t *var_len, WriteMethod **write_method) { /* * The result returned from this function needs to be a pointer to * static data (so that it can be accessed from outside). * Define suitable variables for any type of data we may return. */ static unsigned int long_ret; /* for everything else */ /* * Before returning an answer, we need to check that the request * refers to a valid instance of this object. The utility routine * header_generic can be used to do this for scalar objects. * * This routine header_simple_table does the same thing for "simple" * tables. (See the AGENT.txt file for the definition of a simple table). * * Both these utility routines also set up default values for the * return arguments (assuming the check succeeded). * The name and length are set suitably for the current object, * var_len assumes that the result is an integer of some form, * and write_method assumes that the object cannot be set. * * If these assumptions are correct, this callback routine simply * needs to return a pointer to the appropriate value (using long_ret). * Otherwise, var_len and/or write_method should be set suitably. */ //DEBUGMSDGTL(("example","var_example entered\n")); if (header_generic(vp, name, length, exact, var_len, write_method) == MATCH_FAILED) return NULL; /* * Many object will need to obtain data from the operating system in 101 * order to return the appropriate value. Typically, this is done * here - immediately following the header call, and before the * switch statement. This is particularly appropriate if a single * interface call can return data for all the objects supported. * * This example module does not rely on external data, so no such * calls are needed in this case. */ /* * Now use the magic number from the variable pointer vp to * select the particular object being queried. * In each case, one of the static objects is set up with the * appropriate information, and returned mapped to a u_char * */ switch (vp->magic) { case EXAMPLEINTEGER: /* * Here the length assumption is correct, but the * object is writeable, so we need to set the * write_method pointer as well as the current value. */ long_ret = firstKey++; *var_len = sizeof(long); *write_method = write_exampleint; return (u_char *) &long_ret; default: /* * This will only be triggered if theres a problem with * the coding of the module. SNMP requests that reference * a non-existant OID will be directed elsewhere. * If this branch is reached, log an error, so that * the problem can be investigated. */ //DEBUGMSDGTL(("snmpd", "unknown sub-id %d in examples/var_example\n", //vp->magic)); } /* * If we fall through to here, fail by returning NULL. * This is essentially a continuation of the default case above. */ return NULL; } /********************* * * Writeable object SET handling routines * *********************/ int write_exampleint(int action, u_char *var_val, u_char var_val_type, size_t var_val_len, u_char *statP, 102 oid *name, size_t name_len) { /* Define an arbitrary maximum permissible value */ #define MAX_EXAMPLE_INT 100 static long intval; static long old_intval; switch ( action ) { case RESERVE1: /* * Check that the value being set is acceptable */ if (var_val_type != ASN_INTEGER ) { //DEBUGMSDGTL(("example", "%x not integer type", var_val_type)); return SNMP_ERR_WRONGTYPE; } if (var_val_len > sizeof(long)) { //DEBUGMSDGTL(("example", "wrong length %x", var_val_len)); return SNMP_ERR_WRONGLENGTH; } intval = *((long *) var_val); if (intval > MAX_EXAMPLE_INT) { //DEBUGMSDGTL(("example", "wrong value %x", intval)); return SNMP_ERR_WRONGVALUE; } break; case RESERVE2: /* * This is conventially where any necesary * resources are allocated (e.g. calls to malloc) * Here, we are using static variables * so dont need to worry about this. */ break; case FREE: /* * This is where any of the above resources * are freed again (because one of the other * values being SET failed for some reason). * Again, since we are using static variables * we dont need to worry about this either. */ break; case ACTION: /* * Set the variable as requested. * Note that this may need to be reversed, * so save any information needed to do this. */ old_intval = firstKey; firstKey = intval; 103 break; case UNDO: /* * Something failed, so re-set the * variable to its previous value * (and free any allocated resources). */ firstKey = old_intval; break; case COMMIT: /* * Everything worked, so we can discard any * saved information, and make the change * permanent (e.g. write to the config file). * We also free any allocated resources. * * In this case, theres nothing to do. */ break; } return SNMP_ERR_NOERROR; } Tem-se aqui o cdigo do arquivo de cabealho gerado a partir do exemplo inicial deste apndice, juntamente com o arquivo anterior. /* * Template MIB group interface generated by mib2c - example.h * */ /* Dont include ourselves twice */ #ifndef _MIBGROUP_EXAMPLE_H #define _MIBGROUP_EXAMPLE_H /* * We use header_generic from the util_funcs module, * so make sure this module is included in the agent. */ config_require(util_funcs) /* * Declare our publically-visible functions. * Typically, these will include the initialization and shutdown functions, * the main request callback routine and any writeable object methods. * * Function prototypes are provided for the callback routine (FindVarMethod) * and writeable object methods (WriteMethod). */ extern void init_example(void); 104 extern FindVarMethod var_example; extern WriteMethod write_exampleint; extern WriteMethod write_exampletrap; extern WriteMethod write_exampletrap2; /* * Magic number definitions. * These must be unique for each object implemented within a * single mib module callback routine. * * Typically, these will be the last OID sub-component for * each entry, or integers incrementing from 1. * (which may well result in the same values anyway). * * Here, the second and third objects are form a sub-table and * the magic numbers are chosen to match these OID sub-components. * This is purely for programmer convenience. * All that really matters is that the numbers are unique. */ #define EXAMPLESTRING 1 #define EXAMPLEINTEGER 21 #define EXAMPLEOBJECTID 22 #define EXAMPLETIMETICKS 3 #define EXAMPLEIPADDRESS 4 #define EXAMPLECOUNTER 5 #define EXAMPLEGAUGE 6 #define EXAMPLETRIGGERTRAP 7 #define EXAMPLETRIGGERTRAP2 8 #endif /* _MIBGROUP_EXAMPLE_H */ 105