Snmpv1 V2 E V3 1r6te

S.N.M.P. Filipe Pedrosa, Jos´e Teixeira, Francisco Oliveira Departamento de Ciˆencia de Computadores, FCUP email: [email protected] 17 de Maio de 2004

Conte´ udo 1 Teoria e conceitos sobre SNMP 1.1 O que ´e o SNMP? . . . . . . . . . . . . . . . . . . 1.2 Agentes e Gestores . . . . . . . . . . . . . . . . . . 1.3 SNMP e UDP . . . . . . . . . . . . . . . . . . . . . 1.4 Comunidades SNMP . . . . . . . . . . . . . . . . . 1.5 SMI(Structure Managment Information) . . . . . . 1.6 MIB(Managment Information Base) . . . . . . . . 1.7 Opera¸c˜oes SNMP . . . . . . . . . . . . . . . . . . . 1.7.1 get . . . . . . . . . . . . . . . . . . . . . . . 1.7.2 get-next . . . . . . . . . . . . . . . . . . . . 1.7.3 get-bulk (SNMPv2 e SNMPv3) . . . . . . . . 1.7.4 set . . . . . . . . . . . . . . . . . . . . . . . 1.7.5 get, get-next, get-bulk e set Error Responses 1.7.6 trap . . . . . . . . . . . . . . . . . . . . . . 1.7.7 notification(SNMPv2 e SNMPv3) . . . . . . 1.7.8 inform(SNMPv2 e SNMPv3) . . . . . . . . 1.7.9 report(SNMPv2 e SNMPv3) . . . . . . . . . 1.8 RMON(Remote Monitoring) . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

3 3 3 3 4 5 7 8 9 9 10 11 11 12 15 15 15 15

2 Objectivos do trabalho e da demonstra¸ c˜ ao

16

3 Avalia¸ c˜ ao do SNMP atrav´ es de algumas pe¸ cas de software SNMP 3.1 NetSNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 OpenNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17 17 17

4 Processo experimental 4.1 A experiˆencia . . . . 4.2 O software utilizado 4.2.1 Agentes: . . . 4.2.2 Gestores: . . 4.2.3 Outros . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

17 17 17 17 18 18

5 Net-SNMP 5.1 SNMP get . . . 5.2 SNMP getnext 5.3 SNMP getbulk 5.4 SNMP set . . . 5.5 traps SNMP . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

18 18 21 21 21 28

6 OpenNMS 6.1 Alguma informa¸c˜ao sobre o OpenNMS . . . . . . 6.1.1 Processo de descoberta . . . . . . . . . . . 6.1.2 Capabilities Daemon (capsd) . . . . . . . 6.1.3 Configura¸c˜ao de protocolos . . . . . . . . 6.1.4 SNMP Processo de recolha de informa¸c˜ao 6.2 Configura¸c˜ao do OpenNMS . . . . . . . . . . . . 6.2.1 Equipamentos/Programas . . . . . . . . . 6.2.2 Instala¸c˜ao OpenNMS . . . . . . . . . . . 6.2.3 OpenNMS- os de configura¸c˜ao: . . . . 6.2.4 Erros encontrados e solu¸c˜oes . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

29 29 29 30 31 32 33 33 34 34 36

. . . . .

. . . . .

. . . . .

1

7 Conclus˜ oes 7.1 NetSNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 OpenNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37 37 37 38

8 Biliografia e p´ aginas web

38

2

1

Teoria e conceitos sobre SNMP

1.1

O que ´ e o SNMP?

O SNMP(Simple Network Management Protocol ) como o nome indica, ´e um protocolo simples de gest˜ao de redes. O SNMP foi introduzido em 1988, numa altura em havia uma necessidade de um standard para gerir o dispositivos IP(Internet Protocol ). Ao contr´ario do seu predecessor SGMP(Simple Gateway Management Protocol ) que s´o servia para gerir routers, o SNMP pode ser usado para gerir uma maior diversidade de dispositivos. O SNMP foi desenhado com vista a fornecer um conjunto simples de opera¸c˜oes que permitia gerir estes dispositivos remotamente. Estas opera¸c˜oes para al´em de permitirem manipular dispositivos compat´ıveis com SNMP, tamb´em servem para obter informa¸c˜ao acerca do actual estado do dispositivo, servindo tamb´em como ferramenta de monitoriza¸c˜ao. Por exemplo, o SNMP pode ser usado para desligar interfaces de um router, ou verificar a velocidade a que uma determinada interface est´a a funcionar. Actualmente existem trˆes vers˜oes de SNMP: • SNMP vers˜ao 1 (SNMPv1) em que a seguran¸ca ´e baseada em comunidades, que mais n˜ao s˜ao do que palavras chave, que permite a qualquer aplica¸c˜ao baseada em SNMP que saiba este palavra chave, o o `a um dispositivo SNMP. Tipicamente existem trˆes comunidades nesta vers˜ao, s˜ao elas: read-only , read-write e trap. De notar ainda que n˜ao ´e usado qualquer algoritmo de cifra nesta vers˜ao. • SNMP vers˜ao 2 (SNMPv2), esta vers˜ao ´e muitas vezes referida como SNMPv2 baseada em palavras de comunidade(community string-based SNMPv2). Tecnicamente esta vers˜ao ´e chamada SNMPv2c. Nesta vers˜ ao s˜ao usadas as j´a referidas palavras de comunidade para autentica¸c˜ao. Esta autentica¸c˜ao ´e feita em texto n˜ao cifrado. • SNMP vers˜ao 3 (SNMPv3), esta vers˜ao implementa uma autentica¸c˜ao segura e permite uma canal de comunica¸ca˜o privado entre entidades geridas. Esta vers˜ao j´a usa cifras, permitindo um grau de seguran¸ca que n˜ao havia at´e ent˜ao.

1.2

Agentes e Gestores

No mundo SNMP existem dois tipos de entidades: agentes e gestores. Ou seja, o SNMP baseia-se num modelo agente/gestor. A maior parte do processamento e armazenamento de dados est´a a cargo do sistema de gest˜ao, a que se d´a o nome de gestor neste protocolo, e um subconjunto complementar dessas fun¸c˜oes reside no sistema gerido, a que se d´a o nome de agente. Um gestor ´e um servidor que est´a a correr algum tipo de software que tem a capacidade de efectuar tarefas de gest˜ao de rede. Os gestores s˜ao muitas vezes referidos por NMSs(Network Management Stations), normalmente d´a-se este nome a sistemas que correm software a partir do qual ´e poss´ıvel efectuar todas as tarefas de gest˜ao de rede, por isto mesmo, essas pe¸cas de software s˜ao tamb´em elas conhecidas por NMSs. Um NMS ´e respons´avel por obter informa¸c˜ao dos agentes e por receber notifica¸c˜oes destes, estes dois processos s˜ao tamb´em referidos como polling e trap receiving respectivamente. Os agentes comunicam com os NMS atrav´es de traps(notifica¸c˜oes ass´ıncronas), estas mensagens s˜ao despoletadas por uma mudan¸ca de estado no agente. Os NMSs s˜ao respons´aveis por analisar o conte´ udo de uma trap e agir de acordo com a informa¸c˜ao que cont´em. Por exemplo, quando uma das interfaces de um router se desliga, este pode enviar uma trap ao NMS, o NMS pode seguidamente notificar a pessoa respons´avel pela gest˜ao da rede.

1.3

SNMP e UDP

O SNMP usa o UDP( Datagram Protocol ) como protocolo de transporte. Neste protocolo n˜ao se estabelecem liga¸c˜oes entre entre os intervenientes, ou contr´ario do que acontece no

3

Figura 1: Esquema de troca de mensagens T(Transmission Control Protocol ). O que leva a que n˜ao haja maneira de verificar se um pacote enviado chegou ao destino. Este tipo de controlo ´e feito a n´ıvel da aplica¸c˜ao usando uma estrat´egia de timeout’s, isto ´e, o NMS quando envia uma pedido espera pela resposta um determinado tempo, se esta n˜ao chegar n˜ao causa grandes problemas. No entanto a perda de pacotes no envio de traps pode ser um problema, isto porque, o NMS n˜ao tem maneira de saber se lhe foi enviada alguma trap e o agente n˜ao tem maneira de saber se a trap chegou ao destino(os NMS n˜ao respondem `as traps dos agentes).

Figura 2: SNMP e UDP A vantagem em usar UDP ´e que este ´e bastante leve para uma rede, especialmente se pensarmos em redes congestionadas. O SNMP tamb´em ´e usado para tentar descobrir problemas numa rede, se este fosse implementado em T, para al´em de n˜ao contribuir para resolver problemas, ainda os agravaria. Isto acontece dado `a natureza do T que inunda a rede de retransmiss˜oes para se tentar defender das perdas.

1.4

Comunidades SNMP

As vers˜oes SNMPv1 e SNMPv2c usam a no¸c˜ao de comunidades para estabelecer confian¸ca entre os gestores e os agentes. Os agentes s˜ao configurados com trˆes nomes de comunidade: read-only, read-write e trap. Estes nomes s˜ao palavras chave que controlam diferentes tipos de actividades, a 4

comunidade read-only pode ler valores, mas n˜ao os pode modificar, a comunidade read-write pode ler e escrever. A comunidade de traps permite receber traps do agente. Normalmente o hardware compat´ıvel com SNMP e o software SNMP, j´a tˆem palavras de comunidade predefinidas, tipicamente public para a comunidade read-only, private para a comunidade read-write. As comunica¸co˜es entre agentes e gestores, na vers˜ao SNMPv1 e SNMPv2c, n˜ao nenhum canal seguro, logo as palavras de comunidade trocados entre os agentes de gestores n˜ao s˜ao cifradas. Uma maneira de minorar o problema ´e usando firewalls, configurando a firewall para s´o aceitar pacotes UDP que tenham sido enviados de determinados endere¸cos, no entanto isto n˜ao resolve o problema. A SNMPv3 j´a implementa comunica¸c˜ao segura entre os intervenientes no protocolo. ´ poss´ıvel configurar Os agentes enviam as traps para endere¸cos definidos na sua configura¸c˜ao. E um agente para enviar traps de autentica¸c˜ao falhada(authentication-failure) quando algu´em tenta aceder `a informa¸c˜ao do agente com uma palavra de comunidade falsa.

1.5

SMI(Structure Managment Information)

Structure Managment Information define os nomes dos objectos geridos e especifica os tipos de dados associados.Um objecto gerido ´e qualquer componente de um sistema que faz parte de uma rede e que cont´em informa¸c˜ao de gest˜ao de rede, que pode ser acedida ou at´e modificada provocando altera¸c˜oes na rede ou dando informa¸c˜oes acerca da rede. A informa¸c˜ao recolhida pelo gestor ´e a informa¸c˜ao fornecida pelos objectos geridos. O SMI pode ser visto como o sintaxe usado para defini¸c˜ao dos objectos geridos. No paradigma de gest˜ao de redes gestor/agente, os objectos geridos devem estar ´ıveis fisicamente e logicamente. ´ıvel fisicamente significa que alguma entidade deve verificar o endere¸co e quantificar a informa¸c˜ao de gest˜ao de rede fisicamente. ´ıvel logicamente significa que a informa¸c˜ao de gest˜ao de rede deve ser armazenada e que portanto esta informa¸c˜ao ´e recuper´avel e modific´avel(o SNMP executa a recupera¸c˜ao e modifica¸c˜ao desta informa¸c˜ao). A SMI(estrutura de informa¸c˜ao de gest˜ao) organiza, nomeia e descreve a informa¸c˜ao de modo a que o o l´ogico a esta informa¸c˜ao seja poss´ıvel. Para que os agentes e gestores troquem informa¸c˜ao entre si ´e necess´ario que ambos a entendam, independentemente da forma como a representam internamente. Para que isto aconte¸ca ´e necess´ario a existˆencia de um padr˜ao para o sintaxe abstracto e outro padr˜ao para o sintaxe de transferˆencia. O sintaxe abstracto define especifica¸c˜oes para a nota¸c˜ao de dados. O sintaxe de transferˆencia define codifica¸c˜oes(transmitiveis) para os elementos do sintaxe abstracto. A defini¸c˜ao de objectos geridos ´e constitu´ıda por trˆes atributos: • O nome ou identificador do objecto define um objecto gerido. H´a duas formas de nomes, a forma num´erica e forma human readable. Os objectos geridos s˜ao organizados numa hierarquia em forma de ´arvore. Esta estrutura ´e a base do esquema do nomes do SNMP. O identificador de um objecto ´e constitu´ıdo por uma s´erie de inteiros baseados nos nodos da ´arvore e separados por pontos. A cada n´o da ´arvore, est˜ao associados inteiros e nomes, cada n´o representa um objecto. Na referˆencia a um objecto os inteiros podem ser substituidos pelo nome do n´o. Por exemplo iso.org.dod.internet e 1.3.6.1 referem-se ao mesmo objecto. A estrutura de nomes est´a exemplificada na figura 3. Numa ´arvore de objectos o topo da ´arvore tem o nome de ra´ız, qualquer n´o com filhos d´a pelo nome de sub-´arvore, os n´os sem filhos s˜ao os n´os folha. No contexto SNMP os n´os sub-´arvore s˜ao chamados grupos, isto porque agrupam objectos. Um objecto pode ser escalar ou ter v´arios valores associando-se a uma tabela. Numa referˆencia a um objecto para al´em do seu identificador, indica-se tamb´em a instˆancia do objecto que se pretende, atrav´es se um sufixo colocado a seguir ao identificador. Caso o objecto seja escalar este sufixo ´e 0, se n˜ao for escalar o sufixo identifica a instˆancia que se pretende. Mais concretamente, a descri¸c˜ao de um sistema ´e tem o seguinte identificador 1.3.6.1.2.1.1.1, e ´e um escalar e que portanto a seu valor ´e referido acrescentando .0 ao identificador ficando 1.3.6.1.2.1.1.1.0.

5

Figura 3: Esquema de nomes de objectos • Tipo e sintaxe. O SMI especifica que a ASN.1(Abstract Syntax Notation One) define o sintaxe abstracto . Ou seja, a ASN.1 define os elementos b´asicos da linguagem e fornece regras para combinar elementos em mensagens. A ASN.1 foi desenvolvido com o objectivo de fornecer uma forma de definir informa¸c˜ao estruturada de uma forma que fosse independente da m´aquina. Para este efeito a ASN.1 define tipos de dados b´asicos e tipos de dados que s˜ao baseados em combina¸c˜oes dos tipos de dados b´asicos. Dois exemplos de tipos de dados b´asicos da ASN.1 s˜ao os inteiros e as strings. A ASN.1 define os dados de forma muito semelhante ao que acontece na defini¸c˜ao de vari´aveis numa linguagem de programa¸c˜ao de alto n´ıvel. A ASN.1 usa alguns termos u ´nicos para definir os seus procedimentos, termos esses que incluem defini¸c˜oes de tipos, atribui¸c˜oes de valores, defini¸c˜oes de macros, evoca¸c˜oes e defini¸c˜oes de m´odulos. Para al´em disto a ASN.1 cont´em algumas palavras chave ou sequˆencias de caracteres reservadas, como por exemplo INTEGER, OBJECT e NULL que tˆem significado especial e aparecem escritas em mai´ usculas. Um exemplo de uma defini¸c˜ao de um objecto usando ASN.1 ´e a defini¸c˜ao do objecto sysDescr da MIB-II: sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system’s hardware type, software operating-system, and networking software. This must contain only printable ASCII characters." ::= { system 1 } Em que OBJECT-TYPE ´e uma macro usada para definir objectos. 6

Esta presente na tabela 1 o sum´ario de algumas conven¸c˜oes de escrita da ASN.1. Elementos Tipos Valores Macros M´odulos Palavras chave ASN.1

Conven¸ c˜ ao Letra mai´ uscula no inicio da palavra. Letra min´ uscula no in´ıcio da palavra. Toda a palavra em letras mai´ usculas. Letra inicial em mai´ usculas. Toda a palavra em letras mai´ usculas.

Tabela 1: Sum´ario de algumas conven¸c˜oes de ASN.1 A ASN.1 d´a um significado especial a alguns caracteres, na tabela 2 est´a uma lista de caracteres e o significado que tˆem para a ASN.1. Caracteres − −− ::== | {} [] () ..

Significado N´ umero com sinal. Coment´ario. Atribui¸c˜ao. Op¸c˜oes de uma lista. Delimitam uma lista. Delimitam uma etiqueta. Delimitam uma express˜ao de subtipos. Indica uma amplitude.

Tabela 2: Significado de alguns caracteres para a ASN.1 • Codifica¸c˜ao. As BER(Basic Encoding Rules) definem um padr˜ao para converter as defini¸c˜oes de ASN.1 em codifica¸c˜ao de 8bits(linguagem m´aquina) permitindo assim a comunica¸c˜ao entre sistemas. As BER s˜ao necess´arias porque as descri¸c˜oes de ASN.1 s˜ao leg´ıveis por humanos e devem ser traduzidas de maneira diferente para os v´arios tipos de sistemas. No entanto uma representa¸c˜ao BER ´e sempre igual para qualquer descri¸c˜ao ASN.1 independentemente ´ desta forma que a comunica¸c˜ao entre do sistema que recebeu ou enviou a informa¸c˜ao. E sistemas ´e assegurada, independentemente da sua arquitectura. Pode-se dizer portanto que o a sintaxe ASN.1 ´e usada na representa¸c˜ao interna da informa¸c˜ao de gest˜ao e as BER s˜ao usadas na representa¸c˜ao externa da informa¸c˜ao de gest˜ao.

1.6

MIB(Managment Information Base)

Managment Information Base Pode ser vista como um armaz´em de informa¸c˜ao virtual. Um armaz´em f´ısico tem controlo de invent´ario, tamb´em MIB tem de ter esquemas de controlo de invent´ario. O SMI especifica estes esquemas. Tal como uma grande empresa pode ter v´arios armaz´ens tamb´em existem diferentes tipos de MIBs. Qualquer tipo de informa¸c˜ao de estado ou estat´ıstica ´ıvel pelo NMS est´a definida numa MIB. Uma MIB ´e definida por um conjunto de objectos geriveis, que por sua vez s˜ao definidos usando a SMI. Uma MIB ´e um agrupamento l´ogico de objectos geridos que pertencem a uma determinada tarefa de gest˜ao. Por outro lado uma MIB pode ser vista como uma especifica¸c˜ao que define os objectos geridos que um vendedor ou um dispositivo a. Existem MIBs dispon´ıveis para uso p´ ublico, como ´e o caso das internet standards MIBs. E outras desenvolvidos por fabricantes de hardware, que apenas se adequam a esse harware, s˜ao chamadas as enterprise MIBs. Um exemplo destas MIBs s˜ao MIBs da Cisco desenvolvidas para os seus routers. 7

As ´arvores tais como a presente na figura 3 fornece a estrutura de gest˜ao sendo os ramos e as folhas os objectos geridos. Um dos ramos com especial interesse ´e o ramo internet que tem o identificador 1.3.6.1. Este ramo tem os filhos directory(1), mgmt(2), experimental (3), private(4), security(5), snmpV2 (6), e mail (7). Sendo a sub-´arvore mgmt de bastante importˆancia, j´a que se encarrega de todos os documentos Internet-approved (ou seja, encarrega-se dos padr˜oes estabelecidos), como ´e o caso dos Internet standards MIB-I( RFC 1156) e MIB-II(RFC 1213). Os objectos com prefixo 1.3.6.1.2.1 no identificador s˜ao objectos geridos da MIB-I e MIB-II. Estas duas MIBs s˜ao as MIB de gest˜ao de sistemas numa rede por excelˆencia, ou seja, englobam as informa¸c˜ oes e tarefas de gest˜ao que todos os sistemas de rede possuem. A primeira MIB, a MIB-I, foi publicada em 1990 e dividiu os objectos geridos em oito grupos de modo a simplificar a atribui¸c˜ao e implementa¸c˜ao dos OID, e esses grupos eram System, Interfaces, Address Translation, IP, ICMP, T, UDP, e EGP, em 1991 a MIB-II substituiu a MIB-I.

1.7

Opera¸c˜ oes SNMP

O SNMP inclui um conjunto de comandos de gest˜ao e respostas que permitem efectuar as opera¸c˜oes de gest˜ao. Maior parte das opera¸c˜oes SNMP s˜ao executadas pelo gestor. As opera¸c˜oes executadas pelos agentes s˜ao apenas opera¸c˜oes de notifica¸c˜ao. Uma opera¸c˜ao SNMP compreende a execu¸c˜ao de um ou mais comandos SNMP que podem ou n˜ao ter respostas associadas. Os agentes e os gestores usam a seguinte estrutura para o PDU(Protocol Data Unit): • Conte´ udo – Vers˜ao do SNMP – palavra chave de comunidade(community string) – Um ou mais PDUs SNMP • PDU SNMP – Request ID (n´ umero de sequˆencia) – Error Status – Error Index (se 6= 0 indica o ´ındice do OID que causou o erro) – Lista de OIDs e valores ∗ Valores s˜ao Null para gets • Trap PDU – Enterprise (tipo de objecto que originou a trap) – Agent address(endere¸co do agente que o envia) – Generic trap type – Specific code – Time stamp – Lista de OIDs e valores(relevantes para o NMS) Para dar exemplos das v´arias opera¸c˜oes do SNMP, v˜ao ser referidos alguns comandos que fazem parte dum pacote de software que d´a pelo nome de Net-SNMP, anteriormente conhecido por UCD-SNMP.

8

Figura 4: Opera¸c˜ao Get 1.7.1

get

Esta opera¸c˜ao ´e iniciada pelo NMS que envia um pedido ao agente. O agente recebe o pedido e processa-o, pode haver a possibilidade de n˜ao ser poss´ıvel responder ao pedido, nesta situa¸c˜ao o pedido e ignorado pelo agente. Se for poss´ıvel ao agente processar o pedido este envia ao NMS um get-response. O NMS indica, ao agente, a informa¸c˜ao que necessita atrav´es do OID, ou seja o identificador do objecto. Um exemplo do comando correspondente a esta opera¸c˜ao ´e o snmpget(do pacote net-snmp), que recebe como argumentos o endere¸co do agente SNMP, a palavra de comunidade e o identificador do objecto. Por exemplo: $ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0 system.sysLocation.0=" " Para objectos que est˜ao definidos como tabelas em vez de um 0 coloca-se o n´ umero da linha que se pretende. Esta opera¸c˜ao permite obter informa¸c˜ao de apenas um objecto MIB. 1.7.2

get-next

A opera¸c˜ao get-next permite recolher um conjunto de valores de uma MIB, enviando uma s´erie de comandos. Ou seja, por cada objecto MIB que queremos recolher, os comandos get-next e getresponse s˜ao gerados. O comando get-next percorre uma ´arvore por ordem lexicogr´afica. Visto que o OID ´e uma sequˆencia de inteiros ´e f´acil para uma agente come¸car na ra´ız da sua ´arvore de objectos e percorrer os objectos at´e encontrar o OID que procura. Quando o NMS recebe a resposta do agente para o comando get-next que enviou, o NMS envia outro comando get-next. O NMS continua a fazer isto at´e receber um erro do agente, este erro significa que se chegou ao fim da MIB, ou seja, j´a n˜ao h´a mais objectos para percorrer. Um exemplo de um comando de unix do pacote net-snmp que usa esta opera¸c˜ao ´e o snmpwalk. Este comando ´e invocado da mesma maneira que o snmpget mas em vez de se especificar o OID, basta especificar o ramo da ´arvore a partir do qual queremos que sejam percorridos os objectos. $snmpwalk cisco.ora.com public system system.sysDescr.0 = "Cisco Internetwork Operating System Software ..IOS (tm) 2500 Software (C2500-I-L), Version 11.2(5), RELEASE SOFTWARE (fc1)..Copyright (c) 1986-1997 by cisco Systems, Inc... Compiled Mon 31-Mar-97 19:53 by ckralik" system.sysObjectID.0 = OID: enterprises.9.1.19 system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23 system.sys.0 = " " system.sysName.0 = "cisco.ora.com" system.sysLocation.0 = " " system.sysServices.0 = 6

9

A sequˆencia get-next retorna 7 vari´aveis MIB. Cada um destes objectos faz parte do grupo system como est´a definido no RFC 1213. Como referido acima o get-next ´e funciona com base na ordena¸c˜ao lexicogr´afica da ´arvore de objectos MIB. Assim dado um nome de um grupo, neste caso o system, o agente come¸ca na ra´ız e percorre a ´arvore usando um procedimento semelhante a uma procura de profundidade-primeiro.

Figura 5: Opera¸c˜ao Get-next

1.7.3

get-bulk (SNMPv2 e SNMPv3)

A opera¸c˜ao get-bulk foi introduzida pelo vers˜ao 2 do SNMP. Esta opera¸c˜ao permite `a aplica¸c˜ao de gest˜ao recolher uma sec¸c˜ao de uma tabela de uma s´o vez. O opera¸c˜ao get pode tentar recolher mais de um objecto de uma s´o vez, mas o tamanho das mensagens ´e limitado pela capacidade do agente. Se o agente n˜ao conseguir enviar toda a informa¸c˜ao que a aplica¸c˜ao de gest˜ao pediu, ent˜ao d´a um erro e n˜ao envia nenhuns dados. A opera¸c˜ao get-bulk por outro lado diz ao agente para ele apenas enviara a quantidade de informa¸c˜ao m´axima que conseguir. Isto significa ser poss´ıvel obter informa¸c˜ ao incompleta. A opera¸c˜ao get-bulk usa dois campos; n˜ao-repetidos e repeti¸c˜oes-m´aximas, para proceder `a recolha de informa¸c˜ao. O valor n de n˜ao-repetidos diz `a opera¸c˜ao get-bulk que a informa¸ca˜o dos primeiros n objectos pode ser recolhida usando uma opera¸c˜ao get-next. O valor m de repeti¸c˜oes-m´aximas diz `a opera¸c˜ao get-bulk para tentar at´e m opera¸c˜oes get-next para recolher informa¸ca˜o dos restantes objectos. Um exemplo de um comando unix que usa esta opera¸c˜ao ´e o comando snmpbulkget. $ snmpbulkget -v2c -B 1 3 linux.ora.com public sysDescr ifInOctets ifOutOctets system.sysDescr.0 = "Linux linux 2.2.5-15 3 Thu May 27 19:33:18 EDT 1999 i686" interfaces.ifTable.ifEntry.ifInOctets.1 = 70840 interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840 interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020 interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152 interfaces.ifTable.ifEntry.ifInOctets.3 = 0 interfaces.ifTable.ifEntry.ifOutOctets.3 = 0 10

Neste execu¸c˜ao do comando est´a ser pedida informa¸c˜ao de trˆes objectos, o n´ umero total de valores que vamos obter ´e dado pelo f´ormula n + (m * r), em que n ´e o n´ umero de n˜ao-repetidos, que pode ser visto como o n´ umero de objectos escalares(objectos com apenas um valor) no pedido, neste caso vai ser 1 j´a que o u ´nico objecto escalar ´e o sysDescr, m ´e o n´ umero de repeti¸c˜oesm´aximas, que neste caso ´e arbitrariamente 3, e r ´e o n´ umero de objectos n˜ao escalares no pedido, que neste caso s˜ao 2, ifInOctets e ifOutOctets, o que d´a um resultado de 1+(3*2)=7, que ´e o n´ umero total valores que vamos obter. Como esta opera¸c˜ao n˜ao est´a definida na vers˜ao 1 do SNMP ´e pois necess´ario especificar a vers˜ao do SNMP que queremos usar na chamada do comando com a op¸c˜ao -v2c. Os valores n˜ao-repetidos e repeti¸c˜oes-m´aximas s˜ao especificados respectivamente usando a op¸c˜ao -B 1 3. 1.7.4

set

A opera¸c˜ao set ´e usada para mudar o valor de um objecto gerido, ou para criar uma nova linha numa tabela. S´o os objectos que forem definidos como read-write e write-only podem ser ´ poss´ıvel a um NMS fazer set a mais do que um objecto ao alterados ou criados usando o set. E mesmo tempo.

Figura 6: Opera¸c˜ao Set Para exemplificar o uso desta opera¸c˜ao segue-se um exemplo usando os comandos snmpget e snmpset. $ snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "" $ snmpset cisco.ora.com private system.sysLocation.0 s "Atlanta, GA" system.sysLocation.0 = "Atlanta, GA" $ snmpget cisco.ora.com public system.sysLocation.0 system.sysLocation.0 = "Atlanta, GA" O comando snmpset necessita da read-write community string(private), um endere¸co de agente (cisco.ora.com), a identifica¸c˜ao do objecto(system.sysLocation.0), o tipo de dados com o qual se vai actualizar o objecto(s-string) e os dados(”Atlanta, GA”). O tipo de dados que um objecto aceita est´a definido na MIB. 1.7.5

get, get-next, get-bulk e set Error Responses

As mensagens de erro que o agente pode enviar como resposta, ajudam o NMS a saber se os pedidos get, get-next e set foram processados correctamente. Qualquer uma das opera¸c˜oes provoca mensagens erro de resposta. As mensagens resposta de erro da vers˜ao SNMPv1 s˜ao as indicadas na tabela 3. Estas mensagens de erro contudo n˜ao s˜ao muito robustas. Para resolver este problema a vers˜ao SNMPv2 define mensagens reposta de erro adicionais que s˜ao v´alidas para as seguintes opera¸c˜oes: 11

Nome da mensagem noError(0) tooBig(1) noSuchName(2) badValue(3) readOnly(4) genErr(5)

Descri¸ c˜ ao A opera¸c˜ ao foi executada com sucesso. A resposta ao pedido ´e demasiado grande para caber numa resposta. N˜ao foi encontrado nenhum objecto com o OID especificado. Um objecto read-write ou write-only foi mudado para um valor inconsistente. ´ equivalente ao erro noEste erro geralmente n˜ao ´e utilizado. E SuchName. Este erro ´e gerado sempre que o erro que ocorre n˜ao corresponde a nenhum dos erros acima especificados.

Tabela 3: Mensagens resposta de erro da vers˜ao SNMPv1 get, set, get-next, e get-bulk. Contudo ´e necess´ario que quer agente quer NMS em a vers˜ao 2 do SNMP. Na tabela 4 est˜ao as mensagens resposta de erro que foram introduzidas pela vers˜ao 2 do SNMP. 1.7.6

trap

Uma trap ´e uma notifica¸c˜ao ass´ıncrona do agente para o NMS, este tipo de notifica¸c˜ao s˜ao usadas para informar o NMS que houve uma altera¸c˜ao no agente.

Figura 7: Opera¸c˜ao Trap O agente possui na sua configura¸c˜ao o endere¸co para onde deve enviar as traps que normalmente est´a associado a um NMS. Os NMS n˜ao respondem a traps. Visto que o SNMP usa UDP e que as traps foram desenhadas para encontrar problemas na rede, ´e f´acil uma trap n˜ao chegar ao destino. No entanto esta opera¸c˜ao n˜ao deixa de ter uma grande utilidade, porque mais vale o agente tentar comunicar o problema ao NMS do que simplesmente n˜ao ter nenhuma reac¸c˜ao. Algumas das situa¸c˜oes que podem ser comunicadas por traps. • Uma interface de rede do dispositivo perdeu a liga¸c˜ao `a rede • Uma interface de rede do dispositivo recuperou a liga¸c˜ao `a rede • Tentativa de estabelecimento de uma comunica¸c˜ao com um modem rack falhou. • A ventoinha de um switch ou router deixou de funcionar. Estes s˜ao apenas algumas das situa¸c˜oes. Quando um NMS recebe uma trap este precisa de saber o que significa e a informa¸c˜ao que cont´em. Uma trap ´e identificada pelo identificador gen´erico de traps h´a 7 n´ umeros de traps gen´ericas(0-6). Os v´arios tipos de traps est˜ao descritos na tabela 5. A trap gen´erica 6 engloba 12

Nome da mensagem no(6) wrongType(7)

wrongLength(8)

wrongEncoding(9) wrongValue(10)

noCreation(11) inconsistentValue resourceUnavailable(13) commitFailed(14) undoFailed(15) authorizationError(16) notWritable(17) inconsistentName(18)

Descri¸ c˜ ao Houve uma tentativa de mudar um valor in´ıvel. Isto acontece quando a vari´avel tem um tipo de ACCESS de not-accessible. Um objecto foi actualizado com um valor que n˜ao corresponde ao tipo de dados com que o objecto foi definido. Este erro acontece quando se tenta, por exemplo, substituir o valor de um objecto que ´e de tipo INTEGER por uma string. O valor do objecto foi mudado por um valor que n˜ao corresponde exactamente `a especifica¸c˜ao do objecto. Por exemplo, uma string pode ser definida para ter um n´ umero m´aximo de caracteres. Este erro ocorre quando se tenta substituir o valor do objecto do tipo string por uma string que excede o tamanho definido. Houve uma tentativa de substituir um valor de um objecto usando uma codifica¸c˜ao errada. Uma vari´avel foi substitu´ıda por um valor que n˜ao percebe. Este erro ocorre, por exemplo, quando um objecto ´e definido com uma enumera¸c˜ao e o tipo do valor com que se tentou substituir o valor do objecto, n˜ao corresponde a nenhum dos tipos enumerados. O objecto de que se tentou mudar o valor n˜ao est´a definido na MIB. Um objecto est´a inconsistente e portanto n˜ao aceita novos valores. N˜ao h´a recursos no sistema para executar o pedido. Uma mensagem de resposta ´e enviada com este erro, sempre que uma opera¸c˜ao de set falha. A opera¸c˜ao de set falhou e o agente n˜ao conseguiu repor os valores que foram mudados antes a opera¸c˜ao falhar. Um comando SNMP n˜ao pode ser autenticado, ou seja, palavra chave de comunidade errada. O objecto n˜ao aceita uma opera¸c˜ao de set, apesar de ser suposto aceitar. Houve uma tentativa de efectuar set a uma vari´avel, mas esta falhou porque a vari´avel se encontra num estado qualquer de inconsistˆencia.

Tabela 4: Mensagens resposta de erro que foram introduzidas pela vers˜ao 2 do SNMP

13

Tipo de trap coldStart(0)

warmStart(1) linkDown(2) linkUp(3) authenticationFailure (4) egpNeighborLoss (5) enterpriseSpecific (6)

Descri¸ c˜ ao Indica que o agente reinicializou o sistema. Todas as vari´aveis de gest˜ao v˜ao ser reinicializadas. Este tipo de trap pode ser usado para determinar quando foi adicionado novo hardware `a rede. Quando um dispositivo ´e ligado envia uma traps deste tipo. Indica que o agente se reinicializou. As vari´aveis de gest˜ao n˜ao foram reinicializadas. Esta trap ´e enviada quando uma interface do dispositivo perde a liga¸c˜ao `a rede. O primeiro par objecto valor identifica a interface. Esta trap ´e enviada quando uma interface do dispositivo recupera a liga¸c˜ao `a rede. O primeiro par objecto valor identifica a interface. Indica que algu´em tentou recolher informa¸c˜ao do agente com uma palavra chave de comunidade errada. Indica que se perdeu a liga¸c˜ao a um vizinho EGP(Exterior Gateway Protocol ). Indica que a trap ´e uma entreprise-specific trap. Para processar esta trap o NMS tem de descodificar o n´ umero que especifica a trap, que faz parte da mensagem SNMP.

Tabela 5: tipos de traps da vers˜ao SNMPv1 todas as traps que n˜ao s˜ao as 0-5. As traps que n˜ao se enquadram nas traps 0-5 s˜ao as chamadas entreprise-specific traps, que s˜ao traps definidas por fabricantes de hardware ou utilizadores, estas traps s˜ao identificadas pelo enterprise ID(identifica¸c˜ao do objecto algures no ramo enterprises da MIB) e um n´ umero de trap escolhido pelo fabricante ou utilizador. As traps cont´em informa¸c˜ao em forma de objectos MIB. Para as traps 0-5 o conhecimento do que a trap significa est´a embebido no NMS ou no software que recebe as traps. Os objectos e respectivos valores das enterprise-specific traps s˜ao determinados por quem definiu a trap. Um exemplo de uma defini¸c˜ao de uma enterprise trap ´e a rdbmsOutOfSpace que ´e definida no RFC 1697: rdbmsOutOfSpace TRAP-TYPE ENTERPRISE rdbmsTraps VARIABLES { rdbmsSrvInfoDiskOutOfSpaces } DESCRIPTION "An rdbmsOutOfSpace trap signifies that one of the database servers managed by this agent has been unable to allocate space for one of the databases managed by this agent. Care should be taken to avoid flooding the network with these traps." ::= 2 A enterprise ´e rdbmsTraps o n´ umero da trap ´e 2. Esta trap cont´em o valor da vari´avel rdbmsSrvInfoDiskOutOfSpaces cuja defini¸c˜ao ´e a seguinte: rdbmsSrvInfoDiskOutOfSpaces OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of times the server has been unable to obtain disk space that it wanted, since server startup. This would be inspected by an agent on receipt of an rdbmsOutOfSpace trap." ::= { rdbmsSrvInfoEntry 9 }

14

De todas as vezes que o RDBMS n˜ao consegue alocar espa¸co para a base de dados, o agente envia uma trap. 1.7.7

notification(SNMPv2 e SNMPv3)

Com o objectivo de normalizar o formato PDU das traps SNMPv1 (as traps SNMPv1 tˆem um formato PDU diferente das opera¸c˜oes get e set) a vers˜ao SNMPv2 introduz o tipo NOTIFICATIONTYPE. O formato PDU ´e idˆentico ao do formato PDU das opera¸c˜oes get e set. Assim a defini¸c˜ao das traps ´e feita de maneira diferente, um exemplo ´e a defini¸c˜ao do tipo notifica¸c˜ao gen´erica linkDown. linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifStatus, ifOperStatus } STATUS current DESCRIPTION "A linkDown trap signifies that the SNMPv2 entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 3 } O primeiro objecto ´e uma interface(idIndex ) que transitou da condi¸c˜ao de linkDown para outra qualquer condi¸c˜ao. 1.7.8

inform(SNMPv2 e SNMPv3)

A vers˜ao SNMPv2 introduziu uma nova opera¸c˜ao chamada inform, esta opera¸c˜ao permite comunica¸c˜ao gestor para gestor. Esta opera¸c˜ao ´e u ´til quando h´a a necessidade de existirem v´arios gestores numa rede. Quando uma mensagem inform ´e enviada de gestor para outro o receptor envia uma resposta que informa que a mensagem foi recebida. Esta opera¸c˜ao tamb´em pode ser usada par enviar traps SNMPv2 para um NMS, o que permite ao agente receber uma notifica¸c˜ao quando o NMS recebe a trap. 1.7.9

report(SNMPv2 e SNMPv3)

Esta opera¸c˜ao foi definida para a vers˜ao SNMPv2 mas nunca foi implementada nesta vers˜ao. Contudo faz parte da vers˜ao SNMPv3 e tem por objectivo permitir aos motores SNMP comunicarem uns com os outros. Serve principalmente para ”reportar”problemas com o processamento de mensagens SNMP.

1.8

RMON(Remote Monitoring )

As MIBs RMONv1(RMON) e o RMONv2 est˜ao definidos nos RFC 2819 e 2021 respectivamente. A vers˜ao 1 do RMON fornece ao NMS estat´ısticas a n´ıvel de pacotes de toda a rede LAN ou WAN. A vers˜ao 2 do RMON adiciona estat´ısticas a n´ıvel da rede a de aplica¸c˜oes, `a vers˜ao 1 do RMON. Estas estat´ısticas podem ser recolhidas de v´arias maneiras. Uma delas ´e colocar sondas RMON em todos os segmentos da rede que se quer monitorizar. Existe hardware de rede com funcionalidades RMON, por exemplo os routers cisco e os switchs da 3com que podem servir como sondas RMON. A MIB RMON foi concebida para ser poss´ıvel uma sonda RMON executar num modo offline que permite `a sonda recolher estat´ısticas da rede que monitoriza sem ser necess´ario que um NMS esteja constantemente a pedir informa¸c˜ao. A qualquer altura o NMS pode requerer as estat´ısticas que a sonda tem vindo a recolher. Outra das funcionalidades que ´e poss´ıvel atribuir `as sondas

15

RMON, ´e definir valores que quando atingidos ou ultraados provoquem o envio de traps ao NMS. A MIB RMONv1 define os seguintes grupos. rmon statistics history alarm hosts hostTopN matrix filter capture event

OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT OBJECT

IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER IDENTIFIER

::= ::= ::= ::= ::= ::= ::= ::= ::= ::=

{ { { { { { { { { {

mib-2 16 } rmon 1 } rmon 2 } rmon 3 } rmon 4 } rmon 5 } rmon 6 } rmon 7 } rmon 8 } rmon 9 }

Como referido acima, estes objectos referem-se a estat´ısticas a n´ıvel de pacotes. A MIB RMONv2 define mais objectos.

2

Objectivos do trabalho e da demonstra¸c˜ ao

Dada as potencialidades deste protocolo e sabendo que o seu uso na gest˜ao de redes grandes facilita e muito a tarefa de uma equipa de gest˜ao de redes, tentou-se dar uma ideia daquilo que ´e poss´ıvel fazer com este protocolo. Tendo isto em mente tentou-se analisar algumas op¸c˜oes de software livre que fazem uso deste protocolo para gest˜ao de redes. Existem pe¸cas de sofware complexas que tentam reunir todas as tarefas de gest˜ao num sistema com vista a ser poss´ıvel uma istra¸c˜ao centralizada, essas pe¸cas de software que s˜ao conhecidas de por NMS podem ser bastante complexas de instalar mas facilitam bastante as tarefas de um . O objectivo era portanto dar um quadro geral das utiliza¸c˜oes poss´ıveis deste protocolo, bem como dar exemplos de uso de alguns pacotes de software desenvolvidos a pensar neste protocolo. Gestores no Linux: Existe uma oferta de produtos muito grande de gestores para Linux. Desde os pequenos scripts at´e `as suites profissionais, de produtos de c´odigo aberto a software propriet´ario de custo elevad´ıssimo, temos muito por onde escolher. Na tabela 6 e 7 enunciamos alguns dos NMS dispon´ıveis para Linux. GxSMP Tkined OpensNMS MRTG

Tamb´em conhecido por Gnome Snmp. Contem um construtor para a interface de gest˜ao. O mais popular em Linux. O mais f´acil de personalizar. Tabela 6: NMS’s de c´odigo aberto

Hp OpenView IBM Tivoli Netview BMC CA Unicenter Advetnet OptManager

Familia SNMP da HP; Muito usada. A solu¸c˜ao da IBM; Vocacionada para o B2B. Solu¸c˜ao da Castle Rock.Tab´em muito usada. Especializada para sistemas unix. Com uma interface espectacular;Dif´ıcil de Instalar. Tabela 7: NMS’s propriet´arios

Agentes no Linux: Existe uma variedade de gestores para m´aquinas Linux. Quase todas as suites NMS referidas anteriormente comportam um agente a instalar nas m´aquinas a gerir/monitorizar. Como o SNMP ´e um protocolo aberto e standard podemos usar na mesma os NMS com outros 16

agentes como o SNMPResearch www.int.snmp.com, Concord www.empire.com ou o Net-snmp net-snmp.sourceforge.net. De referir que quase todos os dispositivos ’ip’ como hubs, switchs, routers, impressoras que am SNMP vem com um agente que pode ser configurado de modo a ’trabalhar’ com os gestores. De referir tamb´em que em Linux ao contr´ario do Windows o gestores SNMP padr˜ao n˜ao s˜ao parte integrante do kernel. Assim n˜ao se aumenta desnecessariamente o tamanho do mesmo, ganha-se uma maior facilidade em configurar e extender o agente e ainda se tiram benef´ıcios em termos de seguran¸ca.

3

Avalia¸c˜ ao do SNMP atrav´ es de algumas pe¸cas de software SNMP

3.1

NetSNMP

Como gestores das m´aquinas Linux escolhemos os o Net-snmp pois ´e de c´odigo-aberto, gratuito e extremamente robusto. A comunidade aceita tamb´em o net-snmp como o agente SNMP padr˜ao em redes Linux. O Net-SNMP ´e um pacote de software que inclui: • Um agente extens´ıvel • Uma biblioteca para desenvolvimento (c/python/perl). • Utilit´arios para trocar informa¸c˜ao com os agentes (request/set). • Utilit´arios para gerar e tratar traps (generate/handle). • Utilit´arios que reimplementam os conhecidos utilit´arios unix df e netstat numa vers˜ao SNMP. • Um Tk/perl MIB Browser Ps: No anexo 1 encontrar´a informa¸c˜ao de como instalar e configurar o net-snmp.

3.2

OpenNMS

O openNMS ´e um NMS bastante complexo, feito em jsp este NMS n˜ao utiliza somente o protocolo SNMP para monitoriza¸c˜ao de redes. Este NMS usa alguns m´etodos para descobrir entidades de rede que s˜ao ´ıveis de serem geridas, que fazem uso de pedidos ICMP. Na sec¸c˜ao OpenNMS est´a a an´alise deste software.

4 4.1

Processo experimental A experiˆ encia

Ap´os consolidarmos v´arios conceitos fundamentais do SNMP, partimos para a sua an´alise em detalhe. Para tal montamos uma pequena rede com v´arios computadores pessoais, um hub e um routers a rede est´a exemplificada na figura 8. De seguida usando um programa de capturas de rede, analis´amos as mensagens trocadas entre os v´arios agentes e gestores instalados e configurados nas m´aquinas ligadas `a rede.

4.2 4.2.1

O software utilizado Agentes:

Para os computadores pessoais usamos o agente do net-snmp, configurando-o como um deamon. Para o router usamos o seu agent built-in ap´os sua activa¸c˜ao. 17

Figura 8: Diagrama da rede experimental 4.2.2

Gestores:

Para podermos analisar o protocolo, o papel do gestor ´e executado atrav´es da linha de comandos usando os utilit´arios snmpget, snmpgetnext, snmpbulkget, snmpset e trapd disponibilizados pelo net-snmp. Experimentamos tamb´em posteriormente v´arios NMS como o activeSnmp, OpenNMS, adventNet, etc. 4.2.3

Outros

Como programa de capturas Ethernet usamos o Ethereal.

5

Net-SNMP

O pacote de software Net-SNMP para al´em de permitir transformar qualquer terminal unix num agente SNMP, traz tamb´em um conjunto de programas que implementam as opera¸c˜oes SNMP existentes. Este pacote foi usado para analisar o funcionamente do protocolo SNMP ao n´ıvel mais baixo, isto ´e, para analisar as opera¸c˜oes SNMP. Com o objectivo de analisar as opera¸c˜oes SNMP executou-se cada um dos comandos fornecidos pelo o pacote e procedeu-se `a captura das mensagens trocados. As capturas efectuadas bem como uma pequena an´alise do comando, encontram-se na sec¸c˜ao referente ao comando.

5.1

SNMP get

Exemplo de uma opera¸ c˜ ao get usando os comandos do net-snmp: $ snmpget 10.0.0.2 -v2c -c redes 1.3.6.1.2.1.1.6.0 system.sysUpTime.0 = Timeticks: (586731977) 67 days, 21:48:39.77 Capturas correspondentes na figura 9 e 10.

18

Figura 9: Captura do pacote correspondente a um pedido snmp get

19

Figura 10: Captura do pacote correspondente a uma resposta snmp get

20

An´ alise: Como se pode observar nas capturas o comando snmpget usa o modo de opera¸c˜ao get, que produz um pedido get SNMP que cont´em um OID do objecto que queremos consultar. O agente responde ao pedido enviando uma resposta SNMP que cont´em os valores desejados e o respectivo OID.

5.2

SNMP getnext

Exemplo duma opera¸ c˜ ao getnext usando os comandos do net-snmp: $ snmpwalk 10.0.0.1 -v2c -c

redes system

sysDescr.0 = STRING: "Linux Mandrake gandalf.labredes.dcc.online.pt " sysObjectID.0 = OID: enterprises.hp.nm.hpsystem.10.1.1 sysUpTime.0 = Timeticks: (155274552) 17 days, 23:19:05 sys.0 = STRING: "" sysName.0 = STRING: "gandalf.labredes.dcc.online.pt" sysLocation.0 = STRING: "" sysServices.0 = INTEGER: 72 Capturas correspondentes na figura 11 e 12. An´ alise: Como se pode observar nas capturas o comando snmpgetnext, este gera um sequˆencia de pedidos getnext permitindo percorrer os valores das MIBs sem sabermos os seus OID. Este comando corre todos os elementos da sub´arvore da entidade dada como argumento utilizando o modo de opera¸c˜ao get-next do SNMP.

5.3

SNMP getbulk

Exemplo duma opera¸ c˜ ao getbulk usando os comandos do net-snmp: $ snmpbulkget -v2c -Cn1 -Cr5 -Os -c redes gandalf system ifTable sysDescr.0 = STRING: "Linux gandalf.labredes.dcc.online.pt" ifIndex.1 = INTEGER: 1 ifIndex.2 = INTEGER: 2 ifDescr.1 = STRING: "lo0" ifDescr.2 = STRING: "eth0" Capturas correspondentes na figura 13 e 14. An´ alise: Como se pode observar nas capturas o comando snmpbulkget, este gera um sequˆencia de pedidos getbulk permitindo v´arios objectos, dos que tem m´ ultiplas instˆancias podemos seleccionar as partes desejadas. Para isto ´e usado o modo de opera¸c˜ao get-bulk do SNMP.

5.4

SNMP set

Exemplo duma opera¸ c˜ ao snmpset usando os comandos do net-snmp: $ snmpset

-c

redes -v2c

10.0.0.1 system.sysLocation.0 s "local

Capturas correspondentes na figura 15 e 16. An´ alise: Como se pode observar nas capturas o comando snmpset permitiu-nos modificar um valor de um objecto numa entidade da rede. Neste caso permitiu-nos modicarmos a descri¸c˜ao do nosso router 56000. Este comando usa o modo de opera¸c˜ao snmpset em que ´e enviado um pedido set e ´e recebida uma resposta que d´a conta do sucesso ou n˜ao da opera¸c˜ao. 21

Figura 11: Captura do pacote correspondente a um pedido snmp getnext

22

Figura 12: Captura do pacote correspondente a uma resposta snmp getgnext

23

Figura 13: Captura do pacote correspondente a um pedido snmp getbulk

24

Figura 14: Captura do pacote correspondente a uma resposta snmp getbulk

25

Figura 15: Captura do pacote correspondente a um pedido snmp set

26

Figura 16: Captura do pacote correspondente a uma resposta snmp set

27

5.5

traps SNMP

Exemplo de traps SNMP atrav´ es de eventos na rede $ Para criar-mos um evento de rede desligamos a interface FastEthernet0/0 do router Captura correspondente na figura 17

Figura 17: Captura do pacote correspondente a uma trap LinkDown

An´ alise: Como se pode observar nas capturas, o evento criado por n´os foi reportado atrav´es de uma trap SNMP que prontamente no reportou da falha de liga¸c˜ao ao nosso router. Ap´os restabelecermos a liga¸c˜ao ao router outra trap foi lan¸cada para a rede a informar-nos da modifica¸c˜ao efectuada na rede. A opera¸c˜ao trap snmp ´e portanto um evento ass´ıncrono n˜ao resultando de um pedido do gestores mas por iniciativa dos agentes aquando de eventos ocorridos na rede.

28

6

OpenNMS

O OpenNMS ´e um software de gest˜ao de redes que opt´amos por utilizar devido ao facto de este ser software livre e possuir algumas fun¸c˜oes interessantes. Nas sec¸c˜oes seguintes est´a uma pequena an´alise deste software que a por dar a conhecer alguns t´opicos de interesse relativos ao funcionamento OpenNMS at´e aos os seguidos para colocar este pe¸ca de software a funcionar.

6.1

Alguma informa¸c˜ ao sobre o OpenNMS

Esta sec¸c˜ao cont´em pequenas descri¸c˜oes de algumas coisas que s˜ao necess´arias saber para que seja poss´ıvel compreender o funcionamento deste NMS, j´a que o seu funcionamento n˜ao se baseia apenas no SNMP. 6.1.1

Processo de descoberta

O processo de descoberta ´e dividido em duas partes: 1. descoberta dos endere¸cos ip; (a) cria¸c˜ao de um evento; 2. descoberta do servi¸cos associados a esse endere¸co ip. Este processo ´e levado a cabo por mensagens ping ICMP. Se determinado endere¸co ip responde ao ping enviado pelo NMS ´e gerado um evento (NewSuspect event). O processo de descoberta ´e controlado pelo ficheiro discovery-configuration.xml. (a) discovery-configuration.xml 192.168.0.1 <end>192.168.0.254 file:/opt/OpenNMS/etc/include Este ficheiro controla apenas as redes que o Opennms vai analisar por ICMP. As variaveis que permitem a configura¸c˜ao do processo de an´alise s˜ao: • threads: n´ umero de threads usados para o processo de descoberta. Por defeito este valor ´e 1. • packets-per-second: esta vari´avel controla o n´ umero de pacotes ICMP que s˜ao gerados por Segundo. Por defeito este valor ´e 1. • initial-sleep-time: esta vari´avel indica ao Opennms quando deve iniciar a procura. Por defeito, este valor ´e de 5 minutos. Para um processo de descoberta mais r´apido alterou-se este valor para 1000ms (1 minuto) • restart-sleep-time esta vari´avel indica quando o pr´oximo processo de descoberta ir´a decorrer. Por defeito, este valor ´e de 24h. • timeout: esta vari´avel indicadora do timeout que o processo de descoberta espera por um sinal de vida do endere¸co ip a ser questionado.

29

• retries: esta vari´avel indicadora do n´ umero de tentativas de comunicar com determinado endere¸co ip antes de decidir que o endere¸co n˜ao tem associado qualquer servi¸co ou interface. As configura¸c˜oes por defeito impostas pelas vari´aveis globais apresentadas podem ser alteradas, a qualquer momento, a n´ıvel de cada rede que queremos analisar. Indicamos ao processo de descoberta quais as redes que deve analisar atrav´es das seguintes tags: 1.<specific>ip-address: endere¸ co ip de uma interface especifica 2. start-ip-address <end>end-ip-address 3.<exclude-range> start-ip-address <end>end-ip-address 4. file:ficheiro : em que o ficheiro apontado por file cont´ em endere¸ cos ips (um por linha) que devem ser analisados. Este processo por ICMP ´e limitado uma vez que v´arios servi¸cos podem estar a correr em m´aquinas que ignoram mensagens ICMP. Apesar de n˜ao ter sido testado apresentamos de seguida como proceder nesses casos. /opt/OpenNMS/bin/send-event.pl --interface endere¸ co_ip O script send-event.pl gera um novo evento n˜ao recorrendo ao processo de descoberta. Nesta situa¸c˜ao, o utilizador indica o endere¸co ip da m´aquina que quer analisar. 6.1.2

Capabilities Daemon (capsd)

´ o daemon capsd que recebe os eventos gerados pelo processo de descoberta e analisa a E existˆencia dos v´arios servi¸cos nas interfaces descobertas. Este daemon ´e controlado pelo ficheiro capsd-configuration.xml. 1. capsd-configuration.xml

• rescan-frequency: frequˆencia com que o capsd analisa determinada interface para verificar se novos servi¸cos foram adicionados. Por defeito, este processo ocorre de 24h em 24h. • initial-sleep-time: esta vari´avel indica o intervalo de tempo que o capsd deve esperar para iniciar fun¸c˜oes, ap´os o come¸co do Opennms. Por defeito, este valor ´e de 5 minutos. Para um processo mais r´apido, alterou-se este valor para 1000ms (1 minuto)

30

• management-policy: pode ter um de dois valores: managed ou unmanaged. Managed - todos os endere¸cos ips indicados nos v´arios NewSuspect events s˜ao analisados, excepto se esses endere¸cos estiverem inclu´ıdos num intervalo de endere¸cos ip unmanaged que pode ser definido no fim deste ficheiro. Este ´e o valor por defeito. Unamanaged - todos os endere¸cos ips indicados nos v´arios NewSuspect events s˜ao ignorados, excepto se esses endere¸cos estiverem inclu´ıdos num intervalo de endere¸cos ip managed que pode ser definido no fim deste ficheiro. NOTA: A tag para defini¸c˜ao do intervalo de endere¸cos ip managed ou unmanaged ´e . • max-suspect-thread-pool-size: n´ umero m´aximo de threads que podem ser criados para o processo de an´alise. • max-rescan-thread-pool-size: n´ umero de threads que podem ser criados para o processo de an´alise a interfaces previamente analisadas. • abort-protocol-scans-if-no-route: este parˆametro pode ter dois valores: true e false que indicam como o capds deve actuar no caso de receber mensagens ”no route to host”causadas n˜ao pela falta de liga¸c˜ao entre o capds e o host, mas pela existˆencia de firewalls. True o capsd aborta a procura de servi¸cos nesse endere¸co. False as mensagens ”no route to host”s˜ao ignoradas. O capsd analisa a existˆencia dos seguintes servi¸cos: Citrix, DH, DNS, Domino IIOP, FTP, HTTP, HTTPS, ICMP, IMAP, LDAP, Microsoft Exchange, Notes HTTP, POP3, SMB, SMTP, SNMP e T. Assim que o capsd recebe um NewSuspect event e o endere¸co ip recebido est´a na lista dos endere¸cos ip a serem managed, o deamon analisa a existˆencia de todos os processos acima mencionados. 6.1.3

Configura¸ c˜ ao de protocolos

Como exemplo a configura¸c˜ao a para o protocolo ICMP. <protocol-plugin protocol="ICMP" class-name="org.opennms.netmgt.capsd.IcmpPlugin" scan="on" -defined="false"> <protocol-configuration scan="on" -defined="false"> <property key="timeout" value="4000"/> <property key="retry" value="3"/> <protocol-configuration scan="off" -defined="false"> <protocol-configuration scan="enable" -defined="false"> <specific>192.168.30.1> <property key="timeout" value="2000"/> <property key="retry" value="2"/> Cada protocolo tem associada uma tag protocol-plugin com os seguintes parˆametros: • protocol: este ´e o nome do protocolo. • class-name: indica a classe que deve ser usada para testar este servi¸co,

31

• scan: este parˆametro pode ter os valores ”on”or ”off”que indicam se o capsd deve analisar a existˆencia deste protocolo. • -defined: determina se este protocolo foi adicionado pelo utilizador. A an´alise da existˆencia dos servi¸cos por parte do daemon capsd ´e efectuada fazendo uma liga¸c˜ao para portas pr´e-definidas e testando a mensagem inicial enviada pelo servi¸co a correr. De seguida, apresenta-se a an´alise da tag protocol-plugin para o protocolo SNMP: <protocol-plugin protocol="SNMP" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" -defined="false"> <property key="force version" value="SNMPv1"/> <property key="timeout" value="2000"/> <property key="retry" value="3"/> Atrav´es da propriedade key=force version, definimos a vers˜ao do snmp (SNMPv1 e SNMPv2). 6.1.4

SNMP Processo de recolha de informa¸ c˜ ao

A recolha de informa¸c˜ao ´e efectuada de duas formas: • Polling • Collecting (apenas SNMP) Na recolha por polling os monitores conectam-se a determinado servi¸co e testam se o servi¸co responde adequadamente. O OpenNMS agrupa em pacotes v´arias interfaces para ser mais f´acil a defini¸c˜ao de parˆametros de recolha de informa¸c˜ao. Parˆametros como os servi¸cos e a frequˆencia da recolha constituem as configura¸c˜oes dos pacotes. O poller opera nos servi¸cos e interfaces descobertas pelo daemon capsd. O segundo processo de recolha ´e efectuado por collectors. O OpenNMS apenas define collectors para SNMP. O processo de recolha atrav´es de collectors exige a configura¸c˜ao dos seguintes ficheiros: • snmp-config.xml: Adicionar o conjunto de endere¸cos ip a analisar e a chave comunit´aria. • capsd: o daemon capsd inicia o processo de recolha de informa¸c˜ao. • collectd-configuration.xml: Defini¸c˜ao de pacotes constitu´ıdos por interfaces. • datacollection-config.xml: Defini¸c˜ao do conjunto de informa¸c˜ao snmp (snmp-collections) a recolher por cada pacote. snmp-config.xml O ficheiro snmp-config.xml controla o SNMP. Neste ficheiro encontramos os parˆametros utilizados para a liga¸c˜ao aos agentes SNMP. <snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition version="v2c"> <specific>192.168.0.5 <definition right-community="redes" write-community="redes" retry="4" timeout="2000"> 32

<definition port="1161"> <specific>192.168.5.50 Os parˆametros da tag snmp-config s˜ao: • retry: n´ umero de tentativas para se conectar ao agente SNMP. • timeout: intervalo de tempo que o Opennms espera por uma resposta do agente. • read-community: community string de leitura. • write-community: community string de escrita. (Os sets ainda n˜ao est˜ao dispon´ıveis nesta vers˜ao) • port: define a porta na qual o SNMP est´a a correr (Por defeito ´e 161) • version: vers˜ao do SNMP (SNMPv1 ou SNMPv2c) capsd e SNMP O capsd ao testar a existˆencia do SNMP tenta obter o sysObjectId recorrendo `a community string definida no ficheiro snmp-config.xml. Na verdade o que o capsd faz ´e: • Snmpget -v2c -c redes endere¸co-ip sysObjectId • Snmpbulkget -v2c -c redes endere¸co-ip, se o acima foi bem sucedido.

6.2 6.2.1

Configura¸c˜ ao do OpenNMS Equipamentos/Programas

Programas Utilizados: • OpenNMS • Tomcat4 • PostgreSQL • J2SDK • Ethereal • (SO- Linux Mandrake 9.2) Routers: Cisco 2691: Interfaces: s0/0-192.168.11.253/24 fe0/0-192.168.10.1/24 fe0/1-10.0.0.1/8 Configurado para enviar SNMP traps para o host OPENNMS. Cisco 2503: Interfaces: s0-192.168.11.254/24 e0-192.168.10.254/24 Configurado para enviar SNMP traps para o host OPENNMS. 33

Hubs: Dlink: Endere¸ co Ip: 192.168.10.3/24 e para snmp activado

SNMP: 6.2.2

Community-string (read e write):redes

Instala¸ c˜ ao OpenNMS

Para a instala¸c˜ao do OpenNms recorrer a www.opennms.org. os de instala¸c˜ao: • lynx -source http://install.opennms.org — sh • Abrir uma janela de browser e navegar para a seguinte url: 127.0.0.1:8080/opennms • Inserir / como tokens de autentica¸c˜ao. O script instala automaticamente o tomcat4, a base de dados postgressql. Contudo, tanta o tomcat e o postgressql foram instalados deficientemente. 6.2.3

OpenNMS- os de configura¸ c˜ ao:

Editou-se o ficheiro discovery-configurations.xml e adicionou-se as seguintes linhas: 10.0.0.1 <end>10.0.0.2 192.168.11.253 <end>192.168.11.254 192.168.10.1 <end>192.168.10.254 192.168.12.0 <end>192.168.255.254 Alterou-se o valor do parˆametro initial-sleep-time da tag ¡discovery-configuration¿ para 1000ms. Assim o processo de descoberta inicia 1 segundo ap´os o restart do OpenNMS. Para efeitos de demonstra¸c˜ao diminui-se o valor do parˆametro restart-sleep-time para 5 minutos. Num ambiente de produ¸c˜ao o valor por defeito de 24h ´e o aconselh´avel. Adicionou-se as seguintes linhas ao poller-configurations.xml.

begin="10.0.0.1" end="192.168.0.254"/> begin="192.168.11.253" end="192.168.11.254"/> begin="192.168.10.1" end="192.168.10.254"/> begin="192.168.12.1" end="192.168.255.254"/>

Editou-se o ficheiro capsd-configuration.xml e adicionou-se as seguintes linhas:

34

<protocol-plugin protocol="ICMP" class-name="org.opennms.netmgt.capsd.IcmpPlugin" scan="on" -defined="false"> <protocol-configuration scan="on" -defined="false"> <property key="timeout" value="4000"/> <property key="retry" value="3"/> <protocol-configuration/> Configurou-se o intervalo de endere¸cos ip de forma a tamb´em analisar m´aquinas e servi¸cos na rede dos alunos do CIUP. <protocol-plugin protocol="SNMP" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" -defined="false"> <protocol-configuration scan="on" -defined="false"> <property key="timeout" value="4000"/> <property key="retry" value="3"/> <protocol-configuration/> <protocol-configuration scan="on" -defined="false"> <specific>192.168.11.254 <specific>192.168.11.253 <protocol-configuration/> <protocol-configuration scan="on" -defined="false"> <specific>10.0.0.1 <specific>10.0.0.2 <protocol-configuration/> <property key="force version" value="SNMPv2"/> <property key="timeout" value="2000"/> <property key="retry" value="3"/> <protocol-plugin/> Para a recolha de informa¸c˜ao por SNMP adicionaram-se apenas os endere¸cos da rede criada para a demonstra¸c˜ao uma vez que a chave comunit´aria da rede de produ¸c˜ao do CIUP n˜ao foi fornecida. Uma vez que o capsd analisa servi¸cos em hosts aquando a gera¸c˜ao de um novo evento n˜ao ´e necess´ario iniciar o daemon capsd ap´os o daemon de discoberta. Editou-se o ficheiro snmp-config.xml e adicionou-se as seguintes linhas: <defenition read-community="redes" write-community="redes" retry="4" timeout="2000"> Configurando assim todos os equipamentos com chave comunit´aria de leitura e escrita ”redes” Editou-se o ficheiro collecd-configuration.xml a adicionou-se as seguintes linhas: <package name="tar"> IPADDR IPLIKE *.*.*.* <service name="SNMP" interval="3000" 35

-defined="false" status="on"> <parameter key="collection" value="tar-snmp"/> <parameter key="port" value="161"/> <parameter key="retry" value="3"/> <parameter key="timeout" value="3000"/> Adicionou-se ao ficheiro datacollection-config.xml as linhas: <snmp-collection name="tar-snmp" maxVarsPerPdu="20" snmpStorageFlag="all"> Atrav´es da vari´avel maxVarsPerPdu controla-se o n´ umero de vari´aveis retornadas pelo getBulk efectuado pelo daemon do capsd. Configura¸ c˜ ao do daemon trapd para recep¸ c˜ ao de traps. Adicionou-se as seguintes linhas ao ficheiro eventconf.xml: <mask> <maskelement> <mename>id <mevalue>.1.3.6.1.4.1.9.% Ao adicionar-se .1.3.6.1.4.1.9.% informamos o trapd para analisar apenas traps conhecidas de routers cisco. Para que apenas os eventos enviados por equipamentos Cisco e eventos por defeito sejam considerados retirar todas as tags event-file excepto as linhas: <event-file>/opt/OpenNMS/etc/Cisco.events.xml <event-file>/opt/OpenNMS/etc/default.events.xml Atrav´es destas configura¸c˜oes minimizou-se o processamento na an´alise e recep¸c˜ao de traps por parte do OpenNMS. Configuraram-se todos os daemons a gerarem menos threads dos que por defeito por raz˜oes de preformance condicionas pelo poder de processamento da m´aquina de teste. Iniciou-se os servi¸cos necess´arios ao OpenNMS atrav´es dos comandos: /opt/OpenNMS/bin/opennms.sh start /etc/rc.d/initd/postgresql start /etc/rc.d/initd/tomcat4 start 6.2.4

Erros encontrados e solu¸ c˜ oes

• Tomcat – $JAVA HOME Adicionar ao ficheiro de configura¸c˜ao do tomcat (/etc/tomcat4/tomcat4.conf) a path complete da instala¸c˜ao do Java(/usr/local/java). – Autentica¸ c˜ ao com os tokens / n˜ ao aceite Para resolver este problema ´e necess´ario adicionar ao ficheiro /var/tomcat4/conf/server.xml uma tag para a directoria /opennms. Pode-se realizar esta opera¸c˜ao de duas maneiras: ∗ Autom´aticamente, correndo o script install.pl $OPENNMS_HOME/bin/install.pl -q $OPENNMS_HOME/etc/create.sql ∗ Manualmente, adicionando as seguintes linhas ao ficheiro server.xml: 36

Neste caso a op¸c˜ao a) foi a escolhida. Ap´os o restart do tomcat4 a autentica¸c˜ao foi poss´ıvel. Contudo, surgiu um novo problema . Desta vez a mensagem de erro do tomcat estava relacionada com a base de dados que o opennms utiliza. – O processo tomcat morre tendo como mensagem de erro: Could not send event uei.opennms.org/internal/reloadPollerConfiguration Could not send event uei.opennms.org/internal/reloadasdConfiguration Could not send event uei.opennms.org/internal/reloadCollectorConfiguration Alterar o grupo e o owner dos ficheiros collectd-configuration.xml, poller-configuration.xml e capsd-configuration.xml para tomcat4. • PostgresSql – FATAL 1: IDENT authentication failed for ”postgres” Este erro ´e devido ao facto do postgres n˜ao estar a aceitar liga¸c˜oes do localhost. Para resolver esta situa¸c˜ao adicionou-se as seguintes linhas ao ficheiro /var/lib/pgsql/data/pg hba.conf: local all trust host all 127.0.0.1 255.255.255.255 trust host all x.x.x.x x.x.x.x trust -Endere¸ co ip da m´ aquina de istra¸ c~ ao do OpenNMS #local all ident same

7 7.1

Conclus˜ oes NetSNMP

O NetSNMP ´e um pacote de software de especial interesse para o estudo deste protocolo j´a que tem comandos com as implementa¸c˜oes da opera¸c˜oes SNMP, o que nos permitiu analisar a troca de mensagens SNMP, que ocorrem em cada uma das opera¸c˜oes. Foi poss´ıvel verificar que ´e poss´ıvel transformar qualquer sistema unix num agente SNMP atrav´es deste software para al´em ´e poss´ıvel acrescentar MIBs, expandindo o agente. Al´em disto o pacote traz bibliotecas para c/python/perl, que implementam as opera¸c˜oes SNMP, o d´a o possibilidade de criar software de gest˜ao adaptado as necessidades de istra¸c˜ao. Ou seja, este pacote de software para al´em de ser um bom instrumento de estudo do SNMP, ´e um pacote fundamental para gest˜ao de redes linux, permitindo desenvolver software de gest˜ao bastante completo e de uma maneira bastante f´acil.

7.2

OpenNMS

O processo de simula¸c˜ao foi bem sucedido. A configura¸c˜ao dos routers como agentes SNMP permitiu que estes fossem monitorizados pelo OpenNMS. O OpenNMS revelou ser uma mais valia na monitoriza¸c˜ao de redes. Contudo, para competir com vers˜oes comerciais de gest˜ao de redes o OpenNMS tem de evoluir nos seguintes pontos: 37

• configura¸c˜ao dos v´arios processos de recolha de informa¸c˜ao atrav´es da interface • permitir snmpset • melhorar a documenta¸c˜ao em torno da configura¸c˜ao e instala¸c˜ao • melhorar a interface • efectuar o mapeamento autom´atico da rede • permitir um snmpwalk para efeitos de istra¸c˜ao e de monitoriza¸c˜ao A simula¸c˜ao permitiu analisar e monitorizar uma rede em produ¸c˜ao acentuando ainda mais a necessidade de uma ferramenta como o OpenNMS para uma gest˜ao/monitoriza¸c˜ao centralizada. O processo de configura¸c˜ao do NMS foi trabalhoso, dificultado pela quantidade de ficheiros a alterar. No entanto, ap´os v´arios testes e simula¸c˜oes mais pequenas, foi poss´ıvel chegar a uma configura¸c˜ao est´avel e interessante para efeitos de simula¸c˜ao. O OpenNMS usa v´arios protocolos para descobrir interfaces e servi¸cos numa rede. Assim que uma interface ´e descoberta, esta ´e adicionada a uma lista de interfaces a monitorizar. Os daemons do NMS depois testam continuamente essa interface para descobrir os servi¸cos que nela correm. O processo de monitoriza¸c˜ao por SNMP por parte do OpenNMS est´a a cabo de um daemon que faz o uso de opera¸c˜oes snmpget , snmpbulkget e traps. O processo de recolha de informa¸c˜ao SNMP ainda est´a em fase embrion´aria deixando muito a desejar. Este NMS ainda n˜ao tem e para snmpsets e snmpwalks. O NMS est´a especialmente mal no que toca `a interface para informa¸c˜ao SNMP. Uma mais valia na recolha de informa¸c˜ao snmp ´e a reac¸c˜ao do NMS aquando a recep¸c˜ao de uma trap. O OpenNMS tem funcionalidades de reporting e de aviso muito u ´teis que n˜ao foram analisadas neste trabalho por n˜ao serem um ponto importante de estudo. Este NMS tem e para o RRDTool. Toda a informa¸c˜ao recolhida pelo NMS ´e colocada no direct´orio /var/openms/rrd/snmp sendo necess´ario apenas configurar esta ferramenta de visualiza¸c˜ao para recolher informa¸c˜ao deste direct´orio. Por u ´ltimo, o OpenNMS ´e uma ferramenta de gest˜ao de extrema importˆancia. O uso de uma ferramenta como o OpenNMS simplifica a manuten¸c˜ao e istra¸c˜ao de uma rede. Esta ferramenta tem ainda uma periodo de matura¸c˜ao para ser considerado um player entre NMS.

7.3

SNMP

O SNMP ´e essencial em gest˜ao de redes grandes, j´a que permite centralizar a gest˜ao da rede, facilitando muito a tarefa do grupo de istra¸c˜ao. Um dos principais problemas do SNMP at´e ao lan¸camento da vers˜ao trˆes era a seguran¸ca. Apesar deste problema ter sido resolvido com o lan¸camento da vers˜ao 3, ainda se recorre pouco a esta vers˜ao e dado que este protocolo serve para gerir redes, as falhas de seguran¸ca podem ter efeitos desastrosos. O uso de UDP pode ser um problema, j´a que n˜ao h´a confirma¸c˜ao de mensagens, mas ´e a melhor op¸c˜ao j´a que este protocolo pode ser bastante u ´til em redes congestionadas. O UDP ´e a melhor op¸ca˜o em redes congestionadas. O mecanismo de traps do SNMP ´e especialmente u ´til j´a que permite que o gestor seja notificado de uma ocorrˆencia na rede, sem ter de estar sempre a a inquirir a rede, permitindo ent˜ao uma redu¸ca˜o de tr´afego significativa. Podemos ent˜ao concluir que o SNMP ´e um protocolo de istra¸c˜ao de redes, que possui um grande n´ umero de funcionalidades permitindo facilitar a tarefa do gestor, no entanto deve-se ter especial aten¸c˜ao com as configura¸c˜oes de seguran¸ca.

8

Bibliografia e p´ aginas web • Douglas R. Mauro and Kevin J. Schmidt: Essential SNMP, O’Reilly ,ISBN: 0-596-000200(2001) 38

• Mark A. Miller: Managing Internetworks with SNMP, IDG Books Worldwide, Inc., ISBN: 1558515615 • http://opennms.org • http://www.postgresql.org • http://www-106.ibm.com/developerworks/java/library/j-jmx3/ • http://www.rrdtool.org

39