S.N.M.P.

Filipe Pedrosa, Jos Teixeira, Francisco Oliveira e

Departamento de Cincia de Computadores, FCUP e email: fpedrosa@dcc.online.pt, foliveira@dcc.online.pt, jteixeira@dcc.online.pt 17 de Maio de 2004

Conte do u
1 Teoria e conceitos sobre SNMP 1.1 O que o SNMP? . . . . . . . . . . . . . . . . . . e 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 Operaes SNMP . . . . . . . . . . . . . . . . . . . co 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 notication(SNMPv2 e SNMPv3) . . . . . . 1.7.8 inform(SNMPv2 e SNMPv3) . . . . . . . . 1.7.9 report(SNMPv2 e SNMPv3) . . . . . . . . . 1.8 RMON(Remote Monitoring) . . . . . . . . . . . . 2 Objectivos do trabalho e da demonstrao ca 3 Avaliao do SNMP atravs de algumas peas de software SNMP ca e c 3.1 NetSNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 OpenNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Processo experimental 4.1 A experincia . . . . e 4.2 O software utilizado 4.2.1 Agentes: . . . 4.2.2 Gestores: . . 4.2.3 Outros . . . . 5 Net-SNMP 5.1 SNMP get . . . 5.2 SNMP getnext 5.3 SNMP getbulk 5.4 SNMP set . . . 5.5 traps SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 3 4 5 7 8 9 9 10 11 11 12 15 15 15 15 16 17 17 17 17 17 17 17 18 18 18 18 21 21 21 28 29 29 29 30 31 32 33 33 34 34 36

6 OpenNMS 6.1 Alguma informao sobre o OpenNMS . . . . . . ca 6.1.1 Processo de descoberta . . . . . . . . . . . 6.1.2 Capabilities Daemon (capsd) . . . . . . . 6.1.3 Congurao de protocolos . . . . . . . . ca 6.1.4 SNMP Processo de recolha de informao ca 6.2 Congurao do OpenNMS . . . . . . . . . . . . ca 6.2.1 Equipamentos/Programas . . . . . . . . . 6.2.2 Instalao OpenNMS . . . . . . . . . . . ca 6.2.3 OpenNMS- Passos de congurao: . . . . ca 6.2.4 Erros encontrados e solues . . . . . . . co

7 Concluses o 7.1 NetSNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 OpenNMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Biliograa e pginas web a

37 37 37 38 38

1
1.1

Teoria e conceitos sobre SNMP

O que o SNMP? e

O SNMP(Simple Network Management Protocol ) como o nome indica, um protocolo simples e de gesto de redes. O SNMP foi introduzido em 1988, numa altura em havia uma necessidade a de um standard para gerir o dispositivos IP(Internet Protocol ). Ao contrrio do seu predecessor a SGMP(Simple Gateway Management Protocol ) que s servia para gerir routers, o SNMP pode ser o usado para gerir uma maior diversidade de dispositivos. O SNMP foi desenhado com vista a fornecer um conjunto simples de operaes que permitia co gerir estes dispositivos remotamente. Estas operaes para alm de permitirem manipular dispositivos compat co e veis com SNMP, tambm servem para obter informao acerca do actual estado do dispositivo, servindo tambm e ca e como ferramenta de monitorizao. Por exemplo, o SNMP pode ser usado para desligar interfaces ca de um router, ou vericar a velocidade a que uma determinada interface est a funcionar. a Actualmente existem trs verses de SNMP: e o SNMP verso 1 (SNMPv1) em que a segurana baseada em comunidades, que mais no a c e a so do que palavras chave, que permite a qualquer aplicao baseada em SNMP que saiba a ca este palavra chave, o acesso ` um dispositivo SNMP. Tipicamente existem trs comunidades a e nesta verso, so elas: read-only , read-write e trap. De notar ainda que no usado qualquer a a a e algoritmo de cifra nesta verso. a SNMP verso 2 (SNMPv2), esta verso muitas vezes referida como SNMPv2 baseada a a e em palavras de comunidade(community string-based SNMPv2). Tecnicamente esta verso a e chamada SNMPv2c. Nesta verso so usadas as j referidas palavras de comunidade para a a a autenticao. Esta autenticao feita em texto no cifrado. ca ca e a SNMP verso 3 (SNMPv3), esta verso implementa uma autenticao segura e permite uma a a ca canal de comunicaao privado entre entidades geridas. Esta verso j usa cifras, permitindo c a a um grau de segurana que no havia at ento. c a e a

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 cargo do sistema de gesto, a a a que se d o nome de gestor neste protocolo, e um subconjunto complementar dessas funes a co reside no sistema gerido, a que se d o nome de agente. a Um gestor um servidor que est a correr algum tipo de software que tem a capacidade de e a efectuar tarefas de gesto de rede. Os gestores so muitas vezes referidos por NMSs(Network a a Management Stations), normalmente d-se este nome a sistemas que correm software a partir a do qual poss e vel efectuar todas as tarefas de gesto de rede, por isto mesmo, essas peas de a c software so tambm elas conhecidas por NMSs. Um NMS responsvel por obter informao a e e a ca dos agentes e por receber noticaes destes, estes dois processos so tambm referidos como polling co a e e trap receiving respectivamente. Os agentes comunicam com os NMS atravs de traps(noticaes e co ass ncronas), estas mensagens so despoletadas por uma mudana de estado no agente. Os NMSs a c so responsveis por analisar o contedo de uma trap e agir de acordo com a informao que a a u ca contm. Por exemplo, quando uma das interfaces de um router se desliga, este pode enviar uma e trap ao NMS, o NMS pode seguidamente noticar a pessoa responsvel pela gesto da rede. a a

1.3

SNMP e UDP

O SNMP usa o UDP(User Datagram Protocol ) como protocolo de transporte. Neste protocolo no se estabelecem ligaes entre entre os intervenientes, ou contrrio do que acontece no a co a

Figura 1: Esquema de troca de mensagens TCP(Transmission Control Protocol ). O que leva a que no haja maneira de vericar se um a pacote enviado chegou ao destino. Este tipo de controlo feito a n da aplicao usando uma e vel ca estratgia de timeouts, isto , o NMS quando envia uma pedido espera pela resposta um detere e minado tempo, se esta no chegar no causa grandes problemas. No entanto a perda de pacotes a a no envio de traps pode ser um problema, isto porque, o NMS no tem maneira de saber se lhe foi a enviada alguma trap e o agente no tem maneira de saber se a trap chegou ao destino(os NMS a no respondem `s traps dos agentes). a a

Figura 2: SNMP e UDP A vantagem em usar UDP que este bastante leve para uma rede, especialmente se pensare e mos em redes congestionadas. O SNMP tambm usado para tentar descobrir problemas numa e e rede, se este fosse implementado em TCP, para alm de no contribuir para resolver problemas, e a ainda os agravaria. Isto acontece dado ` natureza do TCP que inunda a rede de retransmisses a o para se tentar defender das perdas.

1.4

Comunidades SNMP

As verses SNMPv1 e SNMPv2c usam a noo de comunidades para estabelecer conana entre o ca c os gestores e os agentes. Os agentes so congurados com trs nomes de comunidade: read-only, a e read-write e trap. Estes nomes so palavras chave que controlam diferentes tipos de actividades, a a 4

comunidade read-only pode ler valores, mas no os pode modicar, a comunidade read-write pode a ler e escrever. A comunidade de traps permite receber traps do agente. Normalmente o hardware compat vel com SNMP e o software SNMP, j tm palavras de comunidade predenidas, a e tipicamente public para a comunidade read-only, private para a comunidade read-write. As comunicaoes entre agentes e gestores, na verso SNMPv1 e SNMPv2c, no nenhum canal seguro, logo c a a as palavras de comunidade trocados entre os agentes de gestores no so cifradas. Uma maneira a a de minorar o problema usando rewalls, congurando a rewall para s aceitar pacotes UDP e o que tenham sido enviados de determinados endereos, no entanto isto no resolve o problema. A c a SNMPv3 j implementa comunicao segura entre os intervenientes no protocolo. a ca Os agentes enviam as traps para endereos denidos na sua congurao. E poss congurar c ca vel um agente para enviar traps de autenticao falhada(authentication-failure) quando algum tenta ca e aceder ` informao do agente com uma palavra de comunidade falsa. a ca

1.5

SMI(Structure Managment Information)

Structure Managment Information dene os nomes dos objectos geridos e especica os tipos de dados associados.Um objecto gerido qualquer componente de um sistema que faz parte e de uma rede e que contm informao de gesto de rede, que pode ser acedida ou at modicada e ca a e provocando alteraes na rede ou dando informaes acerca da rede. A informao recolhida pelo co co ca gestor a informao fornecida pelos objectos geridos. e ca O SMI pode ser visto como o sintaxe usado para denio dos objectos geridos. ca No paradigma de gesto de redes gestor/agente, os objectos geridos devem estar acess a veis sicamente e logicamente. Acess sicamente signica que alguma entidade deve vericar o envel dereo e quanticar a informao de gesto de rede sicamente. Acess logicamente signica que c ca a vel a informao de gesto de rede deve ser armazenada e que portanto esta informao recupervel ca a ca e a e modicvel(o SNMP executa a recuperao e modicao desta informao). A SMI(estrutura a ca ca ca de informao de gesto) organiza, nomeia e descreve a informao de modo a que o acesso lgico ca a ca o a esta informao seja poss ca vel. Para que os agentes e gestores troquem informao entre si necessrio que ambos a entenca e a dam, independentemente da forma como a representam internamente. Para que isto acontea c e necessrio a existncia de um padro para o sintaxe abstracto e outro padro para o sintaxe de a e a a transferncia. O sintaxe abstracto dene especicaes para a notao de dados. O sintaxe de e co ca transferncia dene codicaes(transmitiveis) para os elementos do sintaxe abstracto. e co A denio de objectos geridos constitu por trs atributos: ca e da e O nome ou identicador do objecto dene um objecto gerido. H duas formas de nomes, a a forma numrica e forma human readable. e Os objectos geridos so organizados numa hierarquia em forma de rvore. Esta estrutura a a a base do esquema do nomes do SNMP. O identicador de um objecto constitu por e e do uma srie de inteiros baseados nos nodos da rvore e separados por pontos. A cada n da e a o rvore, esto associados inteiros e nomes, cada n representa um objecto. Na referncia a um a a o e objecto os inteiros podem ser substituidos pelo nome do n. Por exemplo iso.org.dod.internet o e 1.3.6.1 referem-se ao mesmo objecto. A estrutura de nomes est exemplicada na gura a 3. Numa rvore de objectos o topo da rvore tem o nome de ra qualquer n com lhos a a z, o d pelo nome de sub-rvore, os ns sem lhos so os ns folha. No contexto SNMP os ns a a o a o o sub-rvore so chamados grupos, isto porque agrupam objectos. a a Um objecto pode ser escalar ou ter vrios valores associando-se a uma tabela. Numa rea ferncia a um objecto para alm do seu identicador, indica-se tambm a instncia do objecto e e e a que se pretende, atravs se um suxo colocado a seguir ao identicador. Caso o objecto seja e escalar este suxo 0, se no for escalar o suxo identica a instncia que se pretende. Mais e a a concretamente, a descrio de um sistema tem o seguinte identicador 1.3.6.1.2.1.1.1, e ca e um escalar e que portanto a seu valor referido acrescentando .0 ao identicador cando e e 1.3.6.1.2.1.1.1.0.

Figura 3: Esquema de nomes de objectos Tipo e sintaxe. O SMI especica que a ASN.1(Abstract Syntax Notation One) dene o sintaxe abstracto . Ou seja, a ASN.1 dene os elementos bsicos da linguagem e fornece a regras para combinar elementos em mensagens. A ASN.1 foi desenvolvido com o objectivo de fornecer uma forma de denir informao estruturada de uma forma que fosse independente ca da mquina. Para este efeito a ASN.1 dene tipos de dados bsicos e tipos de dados que a a so baseados em combinaes dos tipos de dados bsicos. Dois exemplos de tipos de dados a co a bsicos da ASN.1 so os inteiros e as strings. a a A ASN.1 dene os dados de forma muito semelhante ao que acontece na denio de variveis ca a numa linguagem de programao de alto n ca vel. A ASN.1 usa alguns termos unicos para denir os seus procedimentos, termos esses que in cluem denies de tipos, atribuies de valores, denies de macros, evocaes e denies co co co co co de mdulos. Para alm disto a ASN.1 contm algumas palavras chave ou sequncias de o e e e caracteres reservadas, como por exemplo INTEGER, OBJECT e NULL que tm signicado e especial e aparecem escritas em maisculas. u Um exemplo de uma denio de um objecto usando ASN.1 a denio do objecto sysDescr ca e ca 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 systems hardware type, software operating-system, and networking software. This must contain only printable ASCII characters." ::= { system 1 } Em que OBJECT-TYPE uma macro usada para denir objectos. e 6

Esta presente na tabela 1 o sumrio de algumas convenes de escrita da ASN.1. a co Elementos Tipos Valores Macros Mdulos o Palavras chave ASN.1 Conveno ca Letra maiscula no inicio da palavra. u Letra minscula no in da palavra. u cio Toda a palavra em letras maisculas. u Letra inicial em maisculas. u Toda a palavra em letras maisculas. u

Tabela 1: Sumrio de algumas convenes de ASN.1 a co A ASN.1 d um signicado especial a alguns caracteres, na tabela 2 est uma lista de a a caracteres e o signicado que tm para a ASN.1. e Caracteres ::== | {} [] () .. Signicado Nmero com sinal. u Comentrio. a Atribuio. ca Opes de uma lista. co Delimitam uma lista. Delimitam uma etiqueta. Delimitam uma expresso de subtipos. a Indica uma amplitude.

Tabela 2: Signicado de alguns caracteres para a ASN.1 Codicao. As BER(Basic Encoding Rules) denem um padro para converter as denies ca a co de ASN.1 em codicao de 8bits(linguagem mquina) permitindo assim a comunicao entre ca a ca sistemas. As BER so necessrias porque as descries de ASN.1 so leg a a co a veis por humanos e devem ser traduzidas de maneira diferente para os vrios tipos de sistemas. No entanto a uma representao BER sempre igual para qualquer descrio ASN.1 independentemente ca e ca do sistema que recebeu ou enviou a informao. E desta forma que a comunicao entre ca ca sistemas assegurada, independentemente da sua arquitectura. e Pode-se dizer portanto que o a sintaxe ASN.1 usada na representao interna da informao e ca ca de gesto e as BER so usadas na representao externa da informao de gesto. a a ca ca a

1.6

MIB(Managment Information Base)

Managment Information Base Pode ser vista como um armazm de informao virtual. e ca Um armazm f e sico tem controlo de inventrio, tambm MIB tem de ter esquemas de controlo a e de inventrio. O SMI especica estes esquemas. Tal como uma grande empresa pode ter vrios a a armazns tambm existem diferentes tipos de MIBs. Qualquer tipo de informao de estado ou e e ca estat stica acess pelo NMS est denida numa MIB. Uma MIB denida por um conjunto de vel a e objectos geriveis, que por sua vez so denidos usando a SMI. a Uma MIB um agrupamento lgico de objectos geridos que pertencem a uma determinada e o tarefa de gesto. Por outro lado uma MIB pode ser vista como uma especicao que dene os a ca objectos geridos que um vendedor ou um dispositivo suporta. Existem MIBs dispon veis para uso pblico, como o caso das internet standards MIBs. E u e outras desenvolvidos por fabricantes de hardware, que apenas se adequam a esse harware, so a chamadas as enterprise MIBs. Um exemplo destas MIBs so MIBs da Cisco desenvolvidas para a os seus routers. 7

As rvores tais como a presente na gura 3 fornece a estrutura de gesto sendo os ramos a a e as folhas os objectos geridos. Um dos ramos com especial interesse o ramo internet que e tem o identicador 1.3.6.1. Este ramo tem os lhos directory(1), mgmt(2), experimental (3), private(4), security(5), snmpV2 (6), e mail (7). Sendo a sub-rvore mgmt de bastante importncia, a a j que se encarrega de todos os documentos Internet-approved (ou seja, encarrega-se dos padres a o estabelecidos), como o caso dos Internet standards MIB-I( RFC 1156) e MIB-II(RFC 1213). Os e objectos com prexo 1.3.6.1.2.1 no identicador so objectos geridos da MIB-I e MIB-II. Estas a duas MIBs so as MIB de gesto de sistemas numa rede por excelncia, ou seja, englobam as a a e informaes e tarefas de gesto que todos os sistemas de rede possuem. co a A primeira MIB, a MIB-I, foi publicada em 1990 e dividiu os objectos geridos em oito grupos de modo a simplicar a atribuio e implementao dos OID, e esses grupos eram System, Interfaces, ca ca Address Translation, IP, ICMP, TCP, UDP, e EGP, em 1991 a MIB-II substituiu a MIB-I.

1.7

Operaes SNMP co

O SNMP inclui um conjunto de comandos de gesto e respostas que permitem efectuar as a operaes de gesto. Maior parte das operaes SNMP so executadas pelo gestor. As operaes co a co a co executadas pelos agentes so apenas operaes de noticao. a co ca Uma operao SNMP compreende a execuo de um ou mais comandos SNMP que podem ou ca ca no ter respostas associadas. a Os agentes e os gestores usam a seguinte estrutura para o PDU(Protocol Data Unit): Contedo u Verso do SNMP a palavra chave de comunidade(community string) Um ou mais PDUs SNMP PDU SNMP Request ID (nmero de sequncia) u e Error Status Error Index (se = 0 indica o ndice do OID que causou o erro) Lista de OIDs e valores Valores so Null para gets a Trap PDU Enterprise (tipo de objecto que originou a trap) Agent address(endereo do agente que o envia) c Generic trap type Specic code Time stamp Lista de OIDs e valores(relevantes para o NMS) Para dar exemplos das vrias operaes do SNMP, vo ser referidos alguns comandos que a co a fazem parte dum pacote de software que d pelo nome de Net-SNMP, anteriormente conhecido a por UCD-SNMP.

Figura 4: Operao Get ca 1.7.1 get

Esta operao iniciada pelo NMS que envia um pedido ao agente. O agente recebe o pedido ca e e processa-o, pode haver a possibilidade de no ser poss responder ao pedido, nesta situao a vel ca o pedido e ignorado pelo agente. Se for poss ao agente processar o pedido este envia ao NMS vel um get-response. O NMS indica, ao agente, a informao que necessita atravs do OID, ou seja o identicador ca e do objecto. Um exemplo do comando correspondente a esta operao o snmpget(do pacote net-snmp), que ca e recebe como argumentos o endereo do agente SNMP, a palavra de comunidade e o identicador c do objecto. Por exemplo: $ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0 system.sysLocation.0=" " Para objectos que esto denidos como tabelas em vez de um 0 coloca-se o nmero da linha a u que se pretende. Esta operao permite obter informao de apenas um objecto MIB. ca ca 1.7.2 get-next

A operao get-next permite recolher um conjunto de valores de uma MIB, enviando uma srie ca e de comandos. Ou seja, por cada objecto MIB que queremos recolher, os comandos get-next e getresponse so gerados. O comando get-next percorre uma rvore por ordem lexicogrca. Visto a a a que o OID uma sequncia de inteiros fcil para uma agente comear na ra da sua rvore e e e a c z a de objectos e percorrer os objectos at encontrar o OID que procura. Quando o NMS recebe a e resposta do agente para o comando get-next que enviou, o NMS envia outro comando get-next. O NMS continua a fazer isto at receber um erro do agente, este erro signica que se chegou ao m e da MIB, ou seja, j no h mais objectos para percorrer. Um exemplo de um comando de unix a a a do pacote net-snmp que usa esta operao o snmpwalk. Este comando invocado da mesma ca e e maneira que o snmpget mas em vez de se especicar o OID, basta especicar o ramo da rvore a 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.sysContact.0 = " " system.sysName.0 = "cisco.ora.com" system.sysLocation.0 = " " system.sysServices.0 = 6

A sequncia get-next retorna 7 variveis MIB. Cada um destes objectos faz parte do grupo e a system como est denido no RFC 1213. Como referido acima o get-next funciona com base a e na ordenao lexicogrca da rvore de objectos MIB. Assim dado um nome de um grupo, neste ca a a caso o system, o agente comea na ra e percorre a rvore usando um procedimento semelhante c z a a uma procura de profundidade-primeiro.

Figura 5: Operao Get-next ca

1.7.3

get-bulk (SNMPv2 e SNMPv3)

A operao get-bulk foi introduzida pelo verso 2 do SNMP. Esta operao permite ` aplicao ca a ca a ca de gesto recolher uma seco de uma tabela de uma s vez. O operao get pode tentar recolher a ca o ca mais de um objecto de uma s vez, mas o tamanho das mensagens limitado pela capacidade do o e agente. Se o agente no conseguir enviar toda a informao que a aplicao de gesto pediu, ento a ca ca a a d um erro e no envia nenhuns dados. A operao get-bulk por outro lado diz ao agente para ele a a ca apenas enviara a quantidade de informao mxima que conseguir. Isto signica ser poss obter ca a vel informao incompleta. A operao get-bulk usa dois campos; no-repetidos e repeties-mximas, ca ca a co a para proceder ` recolha de informao. O valor n de no-repetidos diz ` operao get-bulk que a a ca a a ca informaao dos primeiros n objectos pode ser recolhida usando uma operao get-next. O valor m c ca de repeties-mximas diz ` operao get-bulk para tentar at m operaes get-next para recolher co a a ca e co informaao dos restantes objectos. c Um exemplo de um comando unix que usa esta operao o comando snmpbulkget. ca e $ 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 execuo do comando est ser pedida informao de trs objectos, o nmero total de ca a ca e u valores que vamos obter dado pelo frmula n + (m * r), em que n o nmero de no-repetidos, e o e u a que pode ser visto como o nmero de objectos escalares(objectos com apenas um valor) no pedido, u neste caso vai ser 1 j que o unico objecto escalar o sysDescr, m o nmero de repetiesa e e u co mximas, que neste caso arbitrariamente 3, e r o nmero de objectos no escalares no pedido, a e e u a que neste caso so 2, ifInOctets e ifOutOctets, o que d um resultado de 1+(3*2)=7, que o a a e nmero total valores que vamos obter. u Como esta operao no est denida na verso 1 do SNMP pois necessrio especicar a ca a a a e a verso do SNMP que queremos usar na chamada do comando com a opo -v2c. Os valores a ca no-repetidos e repeties-mximas so especicados respectivamente usando a opo -B 1 3. a co a a ca 1.7.4 set

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

Figura 6: Operao Set ca Para exemplicar o uso desta operao segue-se um exemplo usando os comandos snmpget e ca 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 endereo de agente c (cisco.ora.com), a identicao do objecto(system.sysLocation.0), o tipo de dados com o qual se ca vai actualizar o objecto(s-string) e os dados(Atlanta, GA). O tipo de dados que um objecto aceita est denido na MIB. a 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 operaes provoca co mensagens erro de resposta. As mensagens resposta de erro da verso SNMPv1 so as indicadas a a na tabela 3. Estas mensagens de erro contudo no so muito robustas. Para resolver este problema a verso a a a SNMPv2 dene mensagens reposta de erro adicionais que so vlidas para as seguintes operaes: a a co 11

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

Descrio ca A operao foi executada com sucesso. ca A resposta ao pedido demasiado grande para caber numa ree sposta. No foi encontrado nenhum objecto com o OID especicado. a Um objecto read-write ou write-only foi mudado para um valor inconsistente. Este erro geralmente no utilizado. E equivalente ao erro noa e SuchName. Este erro gerado sempre que o erro que ocorre no corresponde e a a nenhum dos erros acima especicados.

Tabela 3: Mensagens resposta de erro da verso SNMPv1 a get, set, get-next, e get-bulk. Contudo necessrio que quer agente quer NMS suportem a verso e a a 2 do SNMP. Na tabela 4 esto as mensagens resposta de erro que foram introduzidas pela verso a a 2 do SNMP. 1.7.6 trap

Uma trap uma noticao ass e ca ncrona do agente para o NMS, este tipo de noticao so ca a usadas para informar o NMS que houve uma alterao no agente. ca

Figura 7: Operao Trap ca O agente possui na sua congurao o endereo para onde deve enviar as traps que normalmente ca c est associado a um NMS. Os NMS no respondem a traps. Visto que o SNMP usa UDP e que as a a traps foram desenhadas para encontrar problemas na rede, fcil uma trap no chegar ao destino. e a a No entanto esta operao no deixa de ter uma grande utilidade, porque mais vale o agente tentar ca a comunicar o problema ao NMS do que simplesmente no ter nenhuma reaco. Algumas das a ca situaes que podem ser comunicadas por traps. co Uma interface de rede do dispositivo perdeu a ligao ` rede ca a Uma interface de rede do dispositivo recuperou a ligao ` rede ca a Tentativa de estabelecimento de uma comunicao com um modem rack falhou. ca A ventoinha de um switch ou router deixou de funcionar. Estes so apenas algumas das situaes. a co Quando um NMS recebe uma trap este precisa de saber o que signica e a informao que ca contm. Uma trap identicada pelo identicador genrico de traps h 7 nmeros de traps e e e a u genricas(0-6). Os vrios tipos de traps esto descritos na tabela 5. A trap genrica 6 engloba e a a e 12

Nome da mensagem noAcess(6) wrongType(7)

wrongLength(8)

wrongEncoding(9) wrongValue(10)

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

Descrio ca Houve uma tentativa de mudar um valor inacess vel. Isto acontece quando a varivel tem um tipo de ACCESS de not-accessible. a Um objecto foi actualizado com um valor que no corresponde ao a tipo de dados com que o objecto foi denido. Este erro acontece quando se tenta, por exemplo, substituir o valor de um objecto que de tipo INTEGER por uma string. e O valor do objecto foi mudado por um valor que no corresponde a exactamente ` especicao do objecto. Por exemplo, uma string a ca pode ser denida para ter um nmero mximo de caracteres. Este u a erro ocorre quando se tenta substituir o valor do objecto do tipo string por uma string que excede o tamanho denido. Houve uma tentativa de substituir um valor de um objecto usando uma codicao errada. ca Uma varivel foi substitu por um valor que no percebe. Este a da a erro ocorre, por exemplo, quando um objecto denido com uma e enumerao e o tipo do valor com que se tentou substituir o valor ca do objecto, no corresponde a nenhum dos tipos enumerados. a O objecto de que se tentou mudar o valor no est denido na a a MIB. Um objecto est inconsistente e portanto no aceita novos valores. a a No h recursos no sistema para executar o pedido. a a Uma mensagem de resposta enviada com este erro, sempre que e uma operao de set falha. ca A operao de set falhou e o agente no conseguiu repor os valores ca a que foram mudados antes a operao falhar. ca Um comando SNMP no pode ser autenticado, ou seja, palavra a chave de comunidade errada. O objecto no aceita uma operao de set, apesar de ser suposto a ca aceitar. Houve uma tentativa de efectuar set a uma varivel, mas esta a falhou porque a varivel se encontra num estado qualquer de ina consistncia. e

Tabela 4: Mensagens resposta de erro que foram introduzidas pela verso 2 do SNMP a

13

Tipo de trap coldStart(0)

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

Descrio ca Indica que o agente reinicializou o sistema. Todas as variveis a de gesto vo ser reinicializadas. Este tipo de trap pode ser usa a ado para determinar quando foi adicionado novo hardware ` rede. a Quando um dispositivo ligado envia uma traps deste tipo. e Indica que o agente se reinicializou. As variveis de gesto no a a a foram reinicializadas. Esta trap enviada quando uma interface do dispositivo perde a e ligao ` rede. O primeiro par objecto valor identica a interface. ca a Esta trap enviada quando uma interface do dispositivo recupera e a ligao ` rede. O primeiro par objecto valor identica a interface. ca a Indica que algum tentou recolher informao do agente com uma e ca palavra chave de comunidade errada. Indica que se perdeu a ligao a um vizinho EGP(Exterior Gateca way Protocol ). Indica que a trap uma entreprise-specic trap. Para processar e esta trap o NMS tem de descodicar o nmero que especica a u trap, que faz parte da mensagem SNMP.

Tabela 5: tipos de traps da verso SNMPv1 a todas as traps que no so as 0-5. As traps que no se enquadram nas traps 0-5 so as chamadas a a a a entreprise-specic traps, que so traps denidas por fabricantes de hardware ou utilizadores, estas a traps so identicadas pelo enterprise ID(identicao do objecto algures no ramo enterprises da a ca MIB) e um nmero de trap escolhido pelo fabricante ou utilizador. As traps contm informao em u e ca forma de objectos MIB. Para as traps 0-5 o conhecimento do que a trap signica est embebido no a NMS ou no software que recebe as traps. Os objectos e respectivos valores das enterprise-specic traps so determinados por quem deniu a trap. Um exemplo de uma denio de uma enterprise a ca trap a rdbmsOutOfSpace que denida no RFC 1697: e e 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 rdbmsTraps o nmero da trap 2. Esta trap contm o valor da varivel rdbmsSe u e e a rvInfoDiskOutOfSpaces cuja denio a seguinte: ca e 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 no consegue alocar espao para a base de dados, o agente envia a c uma trap. 1.7.7 notication(SNMPv2 e SNMPv3)

Com o objectivo de normalizar o formato PDU das traps SNMPv1 (as traps SNMPv1 tm um e formato PDU diferente das operaes get e set) a verso SNMPv2 introduz o tipo NOTIFICATIONco a TYPE. O formato PDU idntico ao do formato PDU das operaes get e set. Assim a denio e e co ca das traps feita de maneira diferente, um exemplo a denio do tipo noticao genrica e e ca ca e linkDown. linkDown NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, 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 uma interface(idIndex ) que transitou da condio de linkDown para outra e ca qualquer condio. ca 1.7.8 inform(SNMPv2 e SNMPv3)

A verso SNMPv2 introduziu uma nova operao chamada inform, esta operao permite a ca ca comunicao gestor para gestor. Esta operao util quando h a necessidade de existirem vrios ca ca e a a gestores numa rede. Quando uma mensagem inform enviada de gestor para outro o receptor e envia uma resposta que informa que a mensagem foi recebida. Esta operao tambm pode ser ca e usada par enviar traps SNMPv2 para um NMS, o que permite ao agente receber uma noticao ca quando o NMS recebe a trap. 1.7.9 report(SNMPv2 e SNMPv3)

Esta operao foi denida para a verso SNMPv2 mas nunca foi implementada nesta verso. ca a a Contudo faz parte da verso SNMPv3 e tem por objectivo permitir aos motores SNMP comunia carem uns com os outros. Serve principalmente para reportarproblemas com o processamento de mensagens SNMP.

1.8

RMON(Remote Monitoring )

As MIBs RMONv1(RMON) e o RMONv2 esto denidos nos RFC 2819 e 2021 respectivaa mente. A verso 1 do RMON fornece ao NMS estat a sticas a n de pacotes de toda a rede LAN vel ou WAN. A verso 2 do RMON adiciona estat a sticas a n da rede a de aplicaes, ` verso 1 do vel co a a RMON. Estas estat sticas podem ser recolhidas de vrias maneiras. Uma delas colocar sondas a e 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 uma sonda RMON executar num modo oine vel que permite ` sonda recolher estat a sticas da rede que monitoriza sem ser necessrio que um NMS a esteja constantemente a pedir informao. A qualquer altura o NMS pode requerer as estat ca sticas que a sonda tem vindo a recolher. Outra das funcionalidades que poss e vel atribuir `s sondas a

15

RMON, denir valores que quando atingidos ou ultrapassados provoquem o envio de traps ao e NMS. A MIB RMONv1 dene 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 dene mais objectos.

Objectivos do trabalho e da demonstrao ca

Dada as potencialidades deste protocolo e sabendo que o seu uso na gesto de redes grandes a facilita e muito a tarefa de uma equipa de gesto de redes, tentou-se dar uma ideia daquilo que a poss e vel fazer com este protocolo. Tendo isto em mente tentou-se analisar algumas opes de co software livre que fazem uso deste protocolo para gesto de redes. a Existem peas de sofware complexas que tentam reunir todas as tarefas de gesto num sistema c a com vista a ser poss uma administrao centralizada, essas peas de software que so conhecidas vel ca c a de por NMS podem ser bastante complexas de instalar mas facilitam bastante as tarefas de um administrador. O objectivo era portanto dar um quadro geral das utilizaes poss co 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 `s suites prossionais, de produtos de cdigo aberto a software proprietrio ea o a 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 Tambm conhecido por Gnome Snmp. e Contem um construtor para a interface de gesto. a O mais popular em Linux. O mais fcil de personalizar. a Tabela 6: NMSs de cdigo aberto o Hp OpenView IBM Tivoli Netview BMC CA Unicenter Advetnet OptManager Familia SNMP da HP; Muito usada. A soluo da IBM; Vocacionada para o B2B. ca Soluo da Castle Rock.Tabm muito usada. ca e Especializada para sistemas unix. Com uma interface espectacular;Dif de Instalar. cil Tabela 7: NMSs proprietrios a Agentes no Linux: Existe uma variedade de gestores para mquinas Linux. Quase todas as a suites NMS referidas anteriormente comportam um agente a instalar nas mquinas a gerir/monitorizar. a Como o SNMP um protocolo aberto e standard podemos usar na mesma os NMS com outros e 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 suportam SNMP vem com um agente que pode ser congurado de modo a trabalhar com os gestores. De referir tambm que em Linux ao contrrio do Windows o gestores SNMP padro no so e a a a a parte integrante do kernel. Assim no se aumenta desnecessariamente o tamanho do mesmo, a ganha-se uma maior facilidade em congurar e extender o agente e ainda se tiram benef cios em termos de segurana. c

3
3.1

Avaliao do SNMP atravs de algumas peas de software ca e c SNMP

NetSNMP

Como gestores das mquinas Linux escolhemos os o Net-snmp pois de cdigo-aberto, gratuito a e o e extremamente robusto. A comunidade aceita tambm o net-snmp como o agente SNMP padro e a em redes Linux. O Net-SNMP um pacote de software que inclui: e Um agente extens vel Uma biblioteca para desenvolvimento (c/python/perl). Utilitrios para trocar informao com os agentes (request/set). a ca Utilitrios para gerar e tratar traps (generate/handle). a Utilitrios que reimplementam os conhecidos utilitrios unix df e netstat numa verso SNMP. a a a Um Tk/perl MIB Browser Ps: No anexo 1 encontrar informao de como instalar e congurar o net-snmp. a ca

3.2

OpenNMS

O openNMS um NMS bastante complexo, feito em jsp este NMS no utiliza somente o e a protocolo SNMP para monitorizao de redes. Este NMS usa alguns mtodos para descobrir ca e entidades de rede que so pass a veis de serem geridas, que fazem uso de pedidos ICMP. Na seco ca OpenNMS est a anlise deste software. a a

4
4.1

Processo experimental
A experincia e

Aps consolidarmos vrios conceitos fundamentais do SNMP, partimos para a sua anlise em o a a detalhe. Para tal montamos uma pequena rede com vrios computadores pessoais, um hub e um a routers a rede est exemplicada na gura 8. De seguida usando um programa de capturas de a rede, analismos as mensagens trocadas entre os vrios agentes e gestores instalados e congurados a a nas mquinas ligadas ` rede. a a

4.2
4.2.1

O software utilizado
Agentes:

Para os computadores pessoais usamos o agente do net-snmp, congurando-o como um deamon. Para o router usamos o seu agent built-in aps sua activao. o ca 17

Figura 8: Diagrama da rede experimental 4.2.2 Gestores:

Para podermos analisar o protocolo, o papel do gestor executado atravs da linha de comandos e e usando os utilitrios snmpget, snmpgetnext, snmpbulkget, snmpset e trapd disponibilizaa dos pelo net-snmp. Experimentamos tambm posteriormente vrios NMS como o activeSnmp, e a OpenNMS, adventNet, etc. 4.2.3 Outros

Como programa de capturas Ethernet usamos o Ethereal.

Net-SNMP

O pacote de software Net-SNMP para alm de permitir transformar qualquer terminal unix e num agente SNMP, traz tambm um conjunto de programas que implementam as operaes SNMP e co existentes. Este pacote foi usado para analisar o funcionamente do protocolo SNMP ao n mais vel baixo, isto , para analisar as operaes SNMP. e co Com o objectivo de analisar as operaes SNMP executou-se cada um dos comandos fornecidos co pelo o pacote e procedeu-se ` captura das mensagens trocados. As capturas efectuadas bem como a uma pequena anlise do comando, encontram-se na seco referente ao comando. a ca

5.1

SNMP get

Exemplo de uma operao get usando os comandos do net-snmp: ca $ 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 gura 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

Anlise: a Como se pode observar nas capturas o comando snmpget usa o modo de operao get, que ca produz um pedido get SNMP que contm um OID do objecto que queremos consultar. O agente e responde ao pedido enviando uma resposta SNMP que contm os valores desejados e o respectivo e OID.

5.2

SNMP getnext
redes system

Exemplo duma operao getnext usando os comandos do net-snmp: ca $ snmpwalk 10.0.0.1 -v2c -c

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 sysContact.0 = STRING: "" sysName.0 = STRING: "gandalf.labredes.dcc.online.pt" sysLocation.0 = STRING: "" sysServices.0 = INTEGER: 72 Capturas correspondentes na gura 11 e 12. Anlise: Como se pode observar nas capturas o comando snmpgetnext, este gera um sequncia a e de pedidos getnext permitindo percorrer os valores das MIBs sem sabermos os seus OID. Este comando corre todos os elementos da subrvore da entidade dada como argumento utilizando o a modo de operao get-next do SNMP. ca

5.3

SNMP getbulk

Exemplo duma operao getbulk usando os comandos do net-snmp: ca $ 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 gura 13 e 14. Anlise: Como se pode observar nas capturas o comando snmpbulkget, este gera um sequncia a e de pedidos getbulk permitindo vrios objectos, dos que tem mltiplas instncias podemos seleca u a cionar as partes desejadas. Para isto usado o modo de operao get-bulk do SNMP. e ca

5.4

SNMP set
-c redes -v2c 10.0.0.1 system.sysLocation.0 s "local

Exemplo duma operao snmpset usando os comandos do net-snmp: ca $ snmpset

Capturas correspondentes na gura 15 e 16. Anlise: Como se pode observar nas capturas o comando snmpset permitiu-nos modicar um a valor de um objecto numa entidade da rede. Neste caso permitiu-nos modicarmos a descrio do ca nosso router 56000. Este comando usa o modo de operao snmpset em que enviado um pedido ca e set e recebida uma resposta que d conta do sucesso ou no da operao. e a a ca 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 atravs de eventos na rede e $ Para criar-mos um evento de rede desligamos a interface FastEthernet0/0 do router Captura correspondente na gura 17

Figura 17: Captura do pacote correspondente a uma trap LinkDown

Anlise: Como se pode observar nas capturas, o evento criado por ns foi reportado atravs de a o e uma trap SNMP que prontamente no reportou da falha de ligao ao nosso router. Aps restaca o belecermos a ligao ao router outra trap foi lanada para a rede a informar-nos da modicao ca c ca efectuada na rede. A operao trap snmp portanto um evento ass ca e ncrono no resultando de um a pedido do gestores mas por iniciativa dos agentes aquando de eventos ocorridos na rede.

28

OpenNMS

O OpenNMS um software de gesto de redes que optmos por utilizar devido ao facto de e a a este ser software livre e possuir algumas funes interessantes. Nas seces seguintes est uma co co a pequena anlise deste software que passa por dar a conhecer alguns tpicos de interesse relativos ao a o funcionamento OpenNMS at aos passos seguidos para colocar este pea de software a funcionar. e c

6.1

Alguma informao sobre o OpenNMS ca

Esta seco contm pequenas descries de algumas coisas que so necessrias saber para que ca e co a a seja poss compreender o funcionamento deste NMS, j que o seu funcionamento no se baseia vel a a apenas no SNMP. 6.1.1 Processo de descoberta

O processo de descoberta dividido em duas partes: e 1. descoberta dos endereos ip; c (a) criao de um evento; ca 2. descoberta do servios associados a esse endereo ip. c c Este processo levado a cabo por mensagens ping ICMP. Se determinado endereo ip ree c sponde ao ping enviado pelo NMS gerado um evento (NewSuspect event). O processo de e descoberta controlado pelo cheiro discovery-conguration.xml. e (a) discovery-conguration.xml <discovery-configuration threads="1" packets-per-second="1" initial-sleep-time="300000" restart-sleep-time="86400000" retries="3" timeout="800"> <include-range retries="2" timeout="3000"> <begin>192.168.0.1</begin> <end>192.168.0.254</end> </include-range> <include-url>file:/opt/OpenNMS/etc/include</include-url> </discovery-configuration> Este cheiro controla apenas as redes que o Opennms vai analisar por ICMP. As variaveis que permitem a congurao do processo de anlise so: ca a a threads: nmero de threads usados para o processo de descoberta. Por defeito u este valor 1. e packets-per-second: esta varivel controla o nmero de pacotes ICMP que so a u a gerados por Segundo. Por defeito este valor 1. e initial-sleep-time: esta varivel indica ao Opennms quando deve iniciar a procura. a Por defeito, este valor de 5 minutos. Para um processo de descoberta mais rpido e a alterou-se este valor para 1000ms (1 minuto) restart-sleep-time esta varivel indica quando o prximo processo de descoberta a o ir decorrer. Por defeito, este valor de 24h. a e timeout: esta varivel indicadora do timeout que o processo de descoberta espera a por um sinal de vida do endereo ip a ser questionado. c

29

 retries: esta varivel indicadora do nmero de tentativas de comunicar com dea u terminado endereo ip antes de decidir que o endereo no tem associado qualquer c c a servio ou interface. c As conguraes por defeito impostas pelas variveis globais apresentadas podem ser co a alteradas, a qualquer momento, a n de cada rede que queremos analisar. Indicamos vel ao processo de descoberta quais as redes que deve analisar atravs das seguintes tags: e 1.<specific>ip-address</specific>: endereo ip de uma interface especifica c 2.<include-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </include-range> 3.<exclude-range> <begin>start-ip-address</begin> <end>end-ip-address</end> </exclude-range> 4.<include-url>file:ficheiro</include-url>: em que o ficheiro apontado por file contm e endereos ips (um por linha) que devem ser analisados. c Este processo por ICMP limitado uma vez que vrios servios podem estar a correr em mquinas e a c a que ignoram mensagens ICMP. Apesar de no ter sido testado apresentamos de seguida como a proceder nesses casos. /opt/OpenNMS/bin/send-event.pl --interface endereo_ip c O script send-event.pl gera um novo evento no recorrendo ao processo de descoberta. Nesta a situao, o utilizador indica o endereo ip da mquina que quer analisar. ca c a 6.1.2 Capabilities Daemon (capsd)

E o daemon capsd que recebe os eventos gerados pelo processo de descoberta e analisa a existncia dos vrios servios nas interfaces descobertas. Este daemon controlado pelo cheiro e a c e capsd-conguration.xml. 1. capsd-conguration.xml

<capsd-configuration rescan-frequency="86400000" initial-sleep-time="300000" management-policy="managed" max-suspect-thread-pool-size = "6" max-rescan-thread-pool-size = "3" abort-protocol-scans-if-no-route = "false"> rescan-frequency: frequncia com que o capsd analisa determinada interface para e vericar se novos servios foram adicionados. Por defeito, este processo ocorre de 24h c em 24h. initial-sleep-time: esta varivel indica o intervalo de tempo que o capsd deve esperar a para iniciar funes, aps o comeo do Opennms. Por defeito, este valor de 5 minutos. co o c e Para um processo mais rpido, alterou-se este valor para 1000ms (1 minuto) a

30

 management-policy: pode ter um de dois valores: managed ou unmanaged. Managed - todos os endereos ips indicados nos vrios NewSuspect events so analc a a isados, excepto se esses endereos estiverem inclu c dos num intervalo de endereos ip c unmanaged que pode ser denido no m deste cheiro. Este o valor por defeito. e Unamanaged - todos os endereos ips indicados nos vrios NewSuspect events so igc a a norados, excepto se esses endereos estiverem inclu c dos num intervalo de endereos ip c managed que pode ser denido no m deste cheiro. NOTA: A tag para denio do ca intervalo de endereos ip managed ou unmanaged c e <ip-management policy="managed|unmanaged">. max-suspect-thread-pool-size: nmero mximo de threads que podem ser criados u a para o processo de anlise. a max-rescan-thread-pool-size: nmero de threads que podem ser criados para o u processo de anlise a interfaces previamente analisadas. a abort-protocol-scans-if-no-route: este parmetro pode ter dois valores: true e false a que indicam como o capds deve actuar no caso de receber mensagens no route to hostcausadas no pela falta de ligao entre o capds e o host, mas pela existncia de a ca e rewalls. True o capsd aborta a procura de servios nesse endereo. c c False as mensagens no route to hostso ignoradas. a O capsd analisa a existncia dos seguintes servios: Citrix, DHCP, DNS, Domino IIOP, FTP, e c HTTP, HTTPS, ICMP, IMAP, LDAP, Microsoft Exchange, Notes HTTP, POP3, SMB, SMTP, SNMP e TCP. Assim que o capsd recebe um NewSuspect event e o endereo ip c recebido est na lista dos endereos ip a serem managed, o deamon analisa a existncia de a c e todos os processos acima mencionados. 6.1.3 Congurao de protocolos ca

Como exemplo a congurao a para o protocolo ICMP. ca <protocol-plugin protocol="ICMP" class-name="org.opennms.netmgt.capsd.IcmpPlugin" scan="on" user-defined="false"> <protocol-configuration scan="on" user-defined="false"> <range begin="192.168.10.0" end="192.168.10.254"/> <property key="timeout" value="4000"/> <property key="retry" value="3"/> </protocol-configuration> <protocol-configuration scan="off" user-defined="false"> <range begin="192.168.20.0" end="192.168.20.254"/> </protocol-configuration> <protocol-configuration scan="enable" user-defined="false"> <specific>192.168.30.1</specific>> </protocol-configuration> <property key="timeout" value="2000"/> <property key="retry" value="2"/> </protocol-plugin> Cada protocolo tem associada uma tag protocol-plugin com os seguintes parmetros: a protocol: este o nome do protocolo. e class-name: indica a classe que deve ser usada para testar este servio, c

31

 scan: este parmetro pode ter os valores onor oque indicam se o capsd deve analisar a a existncia deste protocolo. e user-dened: determina se este protocolo foi adicionado pelo utilizador. A anlise da existncia dos servios por parte do daemon capsd efectuada fazendo uma ligao a e c e ca para portas pr-denidas e testando a mensagem inicial enviada pelo servio a correr. e c De seguida, apresenta-se a anlise da tag protocol-plugin para o protocolo SNMP: a <protocol-plugin protocol="SNMP" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" user-defined="false"> <property key="force version" value="SNMPv1"/> <property key="timeout" value="2000"/> <property key="retry" value="3"/> </protocol-plugin> Atravs da propriedade key=force version, denimos a verso do snmp (SNMPv1 e SNMPv2). e a 6.1.4 SNMP Processo de recolha de informao ca

A recolha de informao efectuada de duas formas: ca e Polling Collecting (apenas SNMP) Na recolha por polling os monitores conectam-se a determinado servio e testam se o servio c c responde adequadamente. O OpenNMS agrupa em pacotes vrias interfaces para ser mais fcil a a a denio de parmetros de recolha de informao. Parmetros como os servios e a frequncia ca a ca a c e da recolha constituem as conguraes dos pacotes. O poller opera nos servios e interfaces co c descobertas pelo daemon capsd. O segundo processo de recolha efectuado por collectors. O e OpenNMS apenas dene collectors para SNMP. O processo de recolha atravs de collectors exige e a congurao dos seguintes cheiros: ca snmp-cong.xml: Adicionar o conjunto de endereos ip a analisar e a chave comunitria. c a capsd: o daemon capsd inicia o processo de recolha de informao. ca collectd-conguration.xml: Denio de pacotes constitu ca dos por interfaces. datacollection-cong.xml: Denio do conjunto de informao snmp (snmp-collections) ca ca a recolher por cada pacote. snmp-cong.xml O cheiro snmp-cong.xml controla o SNMP. Neste cheiro encontramos os parmetros utilizaa dos para a ligao aos agentes SNMP. ca <snmp-config retry="3" timeout="800" read-community="public" write-community="private"> <definition version="v2c"> <specific>192.168.0.5</specific> </definition> <definition right-community="redes" write-community="redes" retry="4" timeout="2000"> <range begin="192.168.1.1" end="192.168.1.254"/> <range begin="192.168.3.1" end="192.168.3.254"/> 32

</definition> <definition port="1161"> <specific>192.168.5.50</specific> </definition> </snmp-config> Os parmetros da tag snmp-cong so: a a retry: nmero de tentativas para se conectar ao agente SNMP. u 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 no esto dispon a a veis nesta verso) a port: dene a porta na qual o SNMP est a correr (Por defeito 161) a e version: verso do SNMP (SNMPv1 ou SNMPv2c) a capsd e SNMP O capsd ao testar a existncia do SNMP tenta obter o sysObjectId recorrendo ` community e a string denida no cheiro snmp-cong.xml. Na verdade o que o capsd faz : e Snmpget -v2c -c redes endereo-ip sysObjectId c Snmpbulkget -v2c -c redes endereo-ip, se passo acima foi bem sucedido. c

6.2
6.2.1

Congurao do OpenNMS ca
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: Endereo Ip: 192.168.10.3/24 c Suporte para snmp activado

SNMP: 6.2.2

Community-string (read e write):redes

Instalao OpenNMS ca

Para a instalao do OpenNms recorrer a www.opennms.org. Passos de instalao: ca ca 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 admin/admin como tokens de autenticao. ca O script instala automaticamente o tomcat4, a base de dados postgressql. Contudo, tanta o tomcat e o postgressql foram instalados decientemente. 6.2.3 OpenNMS- Passos de congurao: ca

Editou-se o cheiro discovery-congurations.xml e adicionou-se as seguintes linhas: <include-range retries="2" timeout="3000"> <begin>10.0.0.1</begin> <end>10.0.0.2</end> </include-range> <include-range retries="2" timeout="3000"> <begin>192.168.11.253</begin> <end>192.168.11.254</end> </include-range> <include-range retries="2" timeout="3000"> <begin>192.168.10.1</begin> <end>192.168.10.254</end> </include-range> <include-range retries="2" timeout="3000"> <begin>192.168.12.0</begin> <end>192.168.255.254</end> </include-range> Alterou-se o valor do parmetro initial-sleep-time da tag discovery-conguration para 1000ms. a Assim o processo de descoberta inicia 1 segundo aps o restart do OpenNMS. Para efeitos de o demonstrao diminui-se o valor do parmetro restart-sleep-time para 5 minutos. Num ambiente ca a de produo o valor por defeito de 24h o aconselhvel. ca e a Adicionou-se as seguintes linhas ao poller-congurations.xml. <include-range <include-range <include-range <include-range 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 cheiro capsd-conguration.xml e adicionou-se as seguintes linhas:

34

<protocol-plugin protocol="ICMP" class-name="org.opennms.netmgt.capsd.IcmpPlugin" scan="on" user-defined="false"> <protocol-configuration scan="on" user-defined="false"> <range begin="0.0.0.0" end="255.255.255.255"/> <property key="timeout" value="4000"/> <property key="retry" value="3"/> <protocol-configuration/> Congurou-se o intervalo de endereos ip de forma a tambm analisar mquinas e servios na c e a c rede dos alunos do CIUP. <protocol-plugin protocol="SNMP" class-name="org.opennms.netmgt.capsd.SnmpPlugin" scan="on" user-defined="false"> <protocol-configuration scan="on" user-defined="false"> <range begin="192.168.10.0" end="192.168.10.254"/> <property key="timeout" value="4000"/> <property key="retry" value="3"/> <protocol-configuration/> <protocol-configuration scan="on" user-defined="false"> <specific>192.168.11.254</specific> <specific>192.168.11.253</specific> <protocol-configuration/> <protocol-configuration scan="on" user-defined="false"> <specific>10.0.0.1</specific> <specific>10.0.0.2</specific> <protocol-configuration/> <property key="force version" value="SNMPv2"/> <property key="timeout" value="2000"/> <property key="retry" value="3"/> <protocol-plugin/> Para a recolha de informao por SNMP adicionaram-se apenas os endereos da rede criada ca c para a demonstrao uma vez que a chave comunitria da rede de produo do CIUP no foi ca a ca a fornecida. Uma vez que o capsd analisa servios em hosts aquando a gerao de um novo evento c ca no necessrio iniciar o daemon capsd aps o daemon de discoberta. a e a o Editou-se o cheiro snmp-cong.xml e adicionou-se as seguintes linhas: <defenition read-community="redes" write-community="redes" retry="4" timeout="2000"> <range begin="10.0.0.1" end="10.0.0.2"/> <range begin="192.168.10.1" end="192.168.10.254"/> <range begin="192.168.11.253" end="192.168.11.254"/> </defenition> Congurando assim todos os equipamentos com chave comunitria de leitura e escrita redes a Editou-se o cheiro collecd-conguration.xml a adicionou-se as seguintes linhas: <package name="tar"> <filter>IPADDR IPLIKE *.*.*.* </filter> <include-range begin="10.0.0.1" end="10.0.0.2"/> <include-range begin="192.168.11.253" end="192.168.11.254"/> <include-range begin="192.168.11.253" end="192.168.11.254"/> <service name="SNMP" interval="3000" 35

user-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"/> </service> </package> Adicionou-se ao cheiro datacollection-cong.xml as linhas: <snmp-collection name="tar-snmp" maxVarsPerPdu="20" snmpStorageFlag="all"> Atravs da varivel maxVarsPerPdu controla-se o nmero de variveis retornadas pelo getBulk e a u a efectuado pelo daemon do capsd. Congurao do daemon trapd para recepo de traps. ca ca Adicionou-se as seguintes linhas ao cheiro eventconf.xml: <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.%</mevalue> </maskelement> </mask> 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-le excepto as linhas: <event-file>/opt/OpenNMS/etc/Cisco.events.xml</event-file> <event-file>/opt/OpenNMS/etc/default.events.xml</event-file> Atravs destas conguraes minimizou-se o processamento na anlise e recepo de traps por e co a ca parte do OpenNMS. Conguraram-se todos os daemons a gerarem menos threads dos que por defeito por razes de preformance condicionas pelo poder de processamento da mquina de teste. o a Iniciou-se os servios necessrios ao OpenNMS atravs dos comandos: /opt/OpenNMS/bin/opennms.sh c a e start /etc/rc.d/initd/postgresql start /etc/rc.d/initd/tomcat4 start 6.2.4 Erros encontrados e solues co

Tomcat $JAVA HOME Adicionar ao cheiro de congurao do tomcat (/etc/tomcat4/tomcat4.conf) a path ca complete da instalao do Java(/usr/local/java). ca Autenticao com os tokens admin/admin no aceite ca a Para resolver este problema necessrio adicionar ao cheiro /var/tomcat4/conf/server.xml e a uma <Context> tag para a directoria /opennms. Pode-se realizar esta operao de duas ca maneiras: Automticamente, correndo o script install.pl a $OPENNMS_HOME/bin/install.pl -q $OPENNMS_HOME/etc/create.sql Manualmente, adicionando as seguintes linhas ao cheiro server.xml: 36

<Context path="/opennms" docBase="opennms" debug="0" reloadable="true"> <Logger className="org.apache.cataline.logger.FileLogger" prefix="localhost_opennms_log." suffix=".txt" timestamp="true"/> <Realm className="org.opennms.web.authenticate.OpenNMSTomcatRealm" homeDir="/opt/OpenNMS/"/> </Context> Neste caso a opo a) foi a escolhida. Aps o restart do tomcat4 a autenticao foi ca o ca 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/reloadCpasdConfiguration Could not send event uei.opennms.org/internal/reloadCollectorConfiguration Alterar o grupo e o owner dos cheiros collectd-conguration.xml, poller-conguration.xml e capsd-conguration.xml para tomcat4. PostgresSql FATAL 1: IDENT authentication failed for user postgres Este erro devido e ao facto do postgres no estar a aceitar ligaes do localhost. Para resolver esta situao a co ca adicionou-se as seguintes linhas ao cheiro /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 -Endereo ip da mquina c a de administra~o do OpenNMS ca #local all ident sameuser

7
7.1

Concluses o
NetSNMP

O NetSNMP um pacote de software de especial interesse para o estudo deste protocolo j que e a tem comandos com as implementaes da operaes SNMP, o que nos permitiu analisar a troca co co de mensagens SNMP, que ocorrem em cada uma das operaes. co Foi poss vel vericar que poss e vel transformar qualquer sistema unix num agente SNMP atravs deste software para alm poss acrescentar MIBs, expandindo o agente. e e e vel Alm disto o pacote traz bibliotecas para c/python/perl, que implementam as operaes SNMP, e co o d o possibilidade de criar software de gesto adaptado as necessidades de administrao. Ou a a ca seja, este pacote de software para alm de ser um bom instrumento de estudo do SNMP, um e e pacote fundamental para gesto de redes linux, permitindo desenvolver software de gesto bastante a a completo e de uma maneira bastante fcil. a

7.2

OpenNMS

O processo de simulao foi bem sucedido. A congurao dos routers como agentes SNMP ca ca permitiu que estes fossem monitorizados pelo OpenNMS. O OpenNMS revelou ser uma mais valia na monitorizao de redes. Contudo, para competir com verses comerciais de gesto de redes o ca o a OpenNMS tem de evoluir nos seguintes pontos: 37

 congurao dos vrios processos de recolha de informao atravs da interface ca a ca e permitir snmpset melhorar a documentao em torno da congurao e instalao ca ca ca melhorar a interface efectuar o mapeamento automtico da rede a permitir um snmpwalk para efeitos de administrao e de monitorizao ca ca A simulao permitiu analisar e monitorizar uma rede em produo acentuando ainda mais a ca ca necessidade de uma ferramenta como o OpenNMS para uma gesto/monitorizao centralizada. a ca O processo de congurao do NMS foi trabalhoso, dicultado pela quantidade de cheiros a ca alterar. No entanto, aps vrios testes e simulaes mais pequenas, foi poss chegar a uma cono a co vel gurao estvel e interessante para efeitos de simulao. O OpenNMS usa vrios protocolos para ca a ca a descobrir interfaces e servios numa rede. Assim que uma interface descoberta, esta adicionada c e e a uma lista de interfaces a monitorizar. Os daemons do NMS depois testam continuamente essa interface para descobrir os servios que nela correm. c O processo de monitorizao por SNMP por parte do OpenNMS est a cabo de um daemon que ca a faz o uso de operaes snmpget , snmpbulkget e traps. O processo de recolha de informao SNMP co ca ainda est em fase embrionria deixando muito a desejar. Este NMS ainda no tem suporte para a a a snmpsets e snmpwalks. O NMS est especialmente mal no que toca ` interface para informao a a ca SNMP. Uma mais valia na recolha de informao snmp a reaco do NMS aquando a recepo ca e ca ca de uma trap. O OpenNMS tem funcionalidades de reporting e de aviso muito uteis que no foram analisadas a neste trabalho por no serem um ponto importante de estudo. a Este NMS tem suporte para o RRDTool. Toda a informao recolhida pelo NMS coloca e cada no directrio /var/openms/rrd/snmp sendo necessrio apenas congurar esta ferramenta de o a visualizao para recolher informao deste directrio. ca ca o Por ultimo, o OpenNMS uma ferramenta de gesto de extrema importncia. O uso de e a a uma ferramenta como o OpenNMS simplica a manuteno e administrao de uma rede. Esta ca ca ferramenta tem ainda uma periodo de maturao para ser considerado um player entre NMS. ca

7.3

SNMP

O SNMP essencial em gesto de redes grandes, j que permite centralizar a gesto da rede, e a a a facilitando muito a tarefa do grupo de administrao. Um dos principais problemas do SNMP at ca e ao lanamento da verso trs era a segurana. Apesar deste problema ter sido resolvido com o c a e c lanamento da verso 3, ainda se recorre pouco a esta verso e dado que este protocolo serve para c a a gerir redes, as falhas de segurana podem ter efeitos desastrosos. c O uso de UDP pode ser um problema, j que no h conrmao de mensagens, mas a melhor a a a ca e opo j que este protocolo pode ser bastante util em redes congestionadas. O UDP a melhor ca a e opao em redes congestionadas. c O mecanismo de traps do SNMP especialmente util j que permite que o gestor seja noticado e a de uma ocorrncia na rede, sem ter de estar sempre a a inquirir a rede, permitindo ento uma e a reduao de trfego signicativa. c a Podemos ento concluir que o SNMP um protocolo de administrao de redes, que possui a e ca um grande nmero de funcionalidades permitindo facilitar a tarefa do gestor, no entanto deve-se u ter especial ateno com as conguraes de segurana. ca co c

Bibliograa e pginas web a

Douglas R. Mauro and Kevin J. Schmidt: Essential SNMP, OReilly ,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