S.N.M.P. Filipe Pedrosa, José Teixeira, Francisco Oliveira

S.N.M.P. Filipe Pedrosa, José Teixeira, Francisco Oliveira Departamento de Ciência de Computadores, FCUP email: fpedrosa@dcc.online.pt, foliveira@dcc.online.pt, jteixeira@dcc.online.pt 17 de Maio de 2004

Conteúdo 1 Teoria e conceitos sobre SNMP 3 1.1 O que é o SNMP?.................................... 3 1.2 Agentes e Gestores.................................... 3 1.3 SNMP e UDP....................................... 3 1.4 Comunidades SNMP................................... 4 1.5 SMI(Structure Managment Information)........................ 5 1.6 MIB(Managment Information Base).......................... 7 1.7 Operações SNMP..................................... 8 1.7.1 get......................................... 9 1.7.2 get-next...................................... 9 1.7.3 get-bulk(snmpv2 e SNMPv3).......................... 10 1.7.4 set......................................... 11 1.7.5 get, get-next, get-bulk e set Error Responses.................. 11 1.7.6 trap........................................ 12 1.7.7 notification(snmpv2 e SNMPv3)........................ 15 1.7.8 inform(snmpv2 e SNMPv3).......................... 15 1.7.9 report(snmpv2 e SNMPv3)........................... 15 1.8 RMON(Remote Monitoring).............................. 15 2 Objectivos do trabalho e da demonstração 16 3 Avaliação do SNMP através de algumas peças de software SNMP 17 3.1 NetSNMP......................................... 17 3.2 OpenNMS......................................... 17 4 Processo experimental 17 4.1 A experiência....................................... 17 4.2 O software utilizado................................... 17 4.2.1 Agentes:...................................... 17 4.2.2 Gestores:..................................... 18 4.2.3 Outros....................................... 18 5 Net-SNMP 18 5.1 SNMP get......................................... 18 5.2 SNMP getnext...................................... 21 5.3 SNMP getbulk...................................... 21 5.4 SNMP set......................................... 21 5.5 traps SNMP........................................ 28 6 OpenNMS 29 6.1 Alguma informação sobre o OpenNMS......................... 29 6.1.1 Processo de descoberta.............................. 29 6.1.2 Capabilities Daemon (capsd).......................... 30 6.1.3 Configuração de protocolos........................... 31 6.1.4 SNMP Processo de recolha de informação................... 32 6.2 Configuração do OpenNMS............................... 33 6.2.1 Equipamentos/Programas............................ 33 6.2.2 Instalação OpenNMS.............................. 34 6.2.3 OpenNMS- Passos de configuração:....................... 34 6.2.4 Erros encontrados e soluções.......................... 36 1

7 Conclusões 37 7.1 NetSNMP......................................... 37 7.2 OpenNMS......................................... 37 7.3 SNMP........................................... 38 8 Biliografia e páginas web 38 2

1 Teoria e conceitos sobre SNMP 1.1 O que é o SNMP? O SNMP(Simple Network Management Protocol) como o nome indica, é um protocolo simples de gestão 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ário do seu predecessor SGMP(Simple Gateway Management Protocol) que só 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ções que permitia gerir estes dispositivos remotamente. Estas operações para além de permitirem manipular dispositivos compatíveis com SNMP, também servem para obter informação acerca do actual estado do dispositivo, servindo também como ferramenta de monitorização. Por exemplo, o SNMP pode ser usado para desligar interfaces de um router, ou verificar a velocidade a que uma determinada interface está a funcionar. Actualmente existem três versões de SNMP: SNMP versão 1 (SNMPv1) em que a segurança é baseada em comunidades, que mais não são do que palavras chave, que permite a qualquer aplicação baseada em SNMP que saiba este palavra chave, o acesso à um dispositivo SNMP. Tipicamente existem três comunidades nesta versão, são elas: read-only, read-write e trap. De notar ainda que não é usado qualquer algoritmo de cifra nesta versão. SNMP versão 2 (SNMPv2), esta versão é muitas vezes referida como SNMPv2 baseada em palavras de comunidade(community string-based SNMPv2). Tecnicamente esta versão é chamada SNMPv2c. Nesta versão são usadas as já referidas palavras de comunidade para autenticação. Esta autenticação é feita em texto não cifrado. SNMP versão 3 (SNMPv3), esta versão implementa uma autenticação segura e permite uma canal de comunicação privado entre entidades geridas. Esta versão já usa cifras, permitindo um grau de segurança que não havia até então. 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 gestão, a que se dá o nome de gestor neste protocolo, e um subconjunto complementar dessas funções reside no sistema gerido, a que se dá o nome de agente. Um gestor é um servidor que está a correr algum tipo de software que tem a capacidade de efectuar tarefas de gestão de rede. Os gestores são muitas vezes referidos por NMSs(Network Management Stations), normalmente dá-se este nome a sistemas que correm software a partir do qual é possível efectuar todas as tarefas de gestão de rede, por isto mesmo, essas peças de software são também elas conhecidas por NMSs. Um NMS é responsável por obter informação dos agentes e por receber notificações destes, estes dois processos são também referidos como polling e trap receiving respectivamente. Os agentes comunicam com os NMS através de traps(notificações assíncronas), estas mensagens são despoletadas por uma mudança de estado no agente. Os NMSs são responsáveis por analisar o conteúdo de uma trap e agir de acordo com a informação que contém. 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ável pela gestão da rede. 1.3 SNMP e UDP O SNMP usa o UDP(User Datagram Protocol) como protocolo de transporte. Neste protocolo não se estabelecem ligações entre entre os intervenientes, ou contrário do que acontece no 3

Figura 1: Esquema de troca de mensagens TCP(Transmission Control Protocol). O que leva a que não haja maneira de verificar se um pacote enviado chegou ao destino. Este tipo de controlo é feito a nível da aplicação usando uma estratégia de timeout s, isto é, o NMS quando envia uma pedido espera pela resposta um determinado tempo, se esta não chegar não causa grandes problemas. No entanto a perda de pacotes no envio de traps pode ser um problema, isto porque, o NMS não tem maneira de saber se lhe foi enviada alguma trap e o agente não tem maneira de saber se a trap chegou ao destino(os NMS não respondem às traps dos agentes). Figura 2: SNMP e UDP A vantagem em usar UDP é que este é bastante leve para uma rede, especialmente se pensarmos em redes congestionadas. O SNMP também é usado para tentar descobrir problemas numa rede, se este fosse implementado em TCP, para além de não contribuir para resolver problemas, ainda os agravaria. Isto acontece dado à natureza do TCP que inunda a rede de retransmissões para se tentar defender das perdas. 1.4 Comunidades SNMP As versões SNMPv1 e SNMPv2c usam a noção de comunidades para estabelecer confiança entre os gestores e os agentes. Os agentes são configurados com três nomes de comunidade: read-only, read-write e trap. Estes nomes são palavras chave que controlam diferentes tipos de actividades, a 4

comunidade read-only pode ler valores, mas não 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á têm palavras de comunidade predefinidas, tipicamente public para a comunidade read-only, private para a comunidade read-write. As comunicações entre agentes e gestores, na versão SNMPv1 e SNMPv2c, não nenhum canal seguro, logo as palavras de comunidade trocados entre os agentes de gestores não são cifradas. Uma maneira de minorar o problema é usando firewalls, configurando a firewall para só aceitar pacotes UDP que tenham sido enviados de determinados endereços, no entanto isto não resolve o problema. A SNMPv3 já implementa comunicação segura entre os intervenientes no protocolo. Os agentes enviam as traps para endereços definidos na sua configuração. É possível configurar um agente para enviar traps de autenticação falhada(authentication-failure) quando alguém tenta aceder à informação 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 é qualquer componente de um sistema que faz parte de uma rede e que contém informação de gestão de rede, que pode ser acedida ou até modificada provocando alterações na rede ou dando informações acerca da rede. A informação recolhida pelo gestor é a informação fornecida pelos objectos geridos. O SMI pode ser visto como o sintaxe usado para definição dos objectos geridos. No paradigma de gestão de redes gestor/agente, os objectos geridos devem estar acessíveis fisicamente e logicamente. Acessível fisicamente significa que alguma entidade deve verificar o endereço e quantificar a informação de gestão de rede fisicamente. Acessível logicamente significa que a informação de gestão de rede deve ser armazenada e que portanto esta informação é recuperável e modificável(o SNMP executa a recuperação e modificação desta informação). A SMI(estrutura de informação de gestão) organiza, nomeia e descreve a informação de modo a que o acesso lógico a esta informação seja possível. Para que os agentes e gestores troquem informação entre si é necessário que ambos a entendam, independentemente da forma como a representam internamente. Para que isto aconteça é necessário a existência de um padrão para o sintaxe abstracto e outro padrão para o sintaxe de transferência. O sintaxe abstracto define especificações para a notação de dados. O sintaxe de transferência define codificações(transmitiveis) para os elementos do sintaxe abstracto. A definição de objectos geridos é constituída por três atributos: O nome ou identificador do objecto define um objecto gerido. Há duas formas de nomes, a forma numérica e forma human readable. Os objectos geridos são organizados numa hierarquia em forma de árvore. Esta estrutura é a base do esquema do nomes do SNMP. O identificador de um objecto é constituído por uma série de inteiros baseados nos nodos da árvore e separados por pontos. A cada nó da árvore, estão associados inteiros e nomes, cada nó representa um objecto. Na referência a um objecto os inteiros podem ser substituidos pelo nome do nó. Por exemplo iso.org.dod.internet e 1.3.6.1 referem-se ao mesmo objecto. A estrutura de nomes está exemplificada na figura 3. Numa árvore de objectos o topo da árvore tem o nome de raíz, qualquer nó com filhos dá pelo nome de sub-árvore, os nós sem filhos são os nós folha. No contexto SNMP os nós sub-árvore são chamados grupos, isto porque agrupam objectos. Um objecto pode ser escalar ou ter vários valores associando-se a uma tabela. Numa referência a um objecto para além do seu identificador, indica-se também a instância do objecto que se pretende, através se um sufixo colocado a seguir ao identificador. Caso o objecto seja escalar este sufixo é 0, se não for escalar o sufixo identifica a instância que se pretende. Mais concretamente, a descrição de um sistema é tem o seguinte identificador 1.3.6.1.2.1.1.1, e é um escalar e que portanto a seu valor é 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ásicos 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ção estruturada de uma forma que fosse independente da máquina. Para este efeito a ASN.1 define tipos de dados básicos e tipos de dados que são baseados em combinações dos tipos de dados básicos. Dois exemplos de tipos de dados básicos da ASN.1 são os inteiros e as strings. A ASN.1 define os dados de forma muito semelhante ao que acontece na definição de variáveis numa linguagem de programação de alto nível. A ASN.1 usa alguns termos únicos para definir os seus procedimentos, termos esses que incluem definições de tipos, atribuições de valores, definições de macros, evocações e definições de módulos. Para além disto a ASN.1 contém algumas palavras chave ou sequências de caracteres reservadas, como por exemplo INTEGER, OBJECT e NULL que têm significado especial e aparecem escritas em maiúsculas. Um exemplo de uma definição de um objecto usando ASN.1 é a definição 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 é uma macro usada para definir objectos. 6

Esta presente na tabela 1 o sumário de algumas convenções de escrita da ASN.1. Elementos Tipos Valores Macros Módulos Palavras chave ASN.1 Convenção Letra maiúscula no inicio da palavra. Letra minúscula no início da palavra. Toda a palavra em letras maiúsculas. Letra inicial em maiúsculas. Toda a palavra em letras maiúsculas. Tabela 1: Sumário de algumas convenções de ASN.1 A ASN.1 dá um significado especial a alguns caracteres, na tabela caracteres e o significado que têm para a ASN.1. 2 está uma lista de Caracteres Significado Número com sinal. Comentário. ::== Atribuição. Opções de uma lista. {} Delimitam uma lista. [] Delimitam uma etiqueta. () Delimitam uma expressão de subtipos... Indica uma amplitude. Tabela 2: Significado de alguns caracteres para a ASN.1 Codificação. As BER(Basic Encoding Rules) definem um padrão para converter as definições de ASN.1 em codificação de 8bits(linguagem máquina) permitindo assim a comunicação entre sistemas. As BER são necessárias porque as descrições de ASN.1 são legíveis por humanos e devem ser traduzidas de maneira diferente para os vários tipos de sistemas. No entanto uma representação BER é sempre igual para qualquer descrição ASN.1 independentemente do sistema que recebeu ou enviou a informação. É desta forma que a comunicação entre sistemas é assegurada, independentemente da sua arquitectura. Pode-se dizer portanto que o a sintaxe ASN.1 é usada na representação interna da informação de gestão e as BER são usadas na representação externa da informação de gestão. 1.6 MIB(Managment Information Base) Managment Information Base Pode ser vista como um armazém de informação virtual. Um armazém físico tem controlo de inventário, também MIB tem de ter esquemas de controlo de inventário. O SMI especifica estes esquemas. Tal como uma grande empresa pode ter vários armazéns também existem diferentes tipos de MIBs. Qualquer tipo de informação de estado ou estatística acessível pelo NMS está definida numa MIB. Uma MIB é definida por um conjunto de objectos geriveis, que por sua vez são definidos usando a SMI. Uma MIB é um agrupamento lógico de objectos geridos que pertencem a uma determinada tarefa de gestão. Por outro lado uma MIB pode ser vista como uma especificação que define os objectos geridos que um vendedor ou um dispositivo suporta. Existem MIBs disponíveis para uso público, como é o caso das internet standards MIBs. E outras desenvolvidos por fabricantes de hardware, que apenas se adequam a esse harware, são chamadas as enterprise MIBs. Um exemplo destas MIBs são MIBs da Cisco desenvolvidas para os seus routers. 7

As árvores tais como a presente na figura 3 fornece a estrutura de gestão sendo os ramos e as folhas os objectos geridos. Um dos ramos com especial interesse é 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-árvore mgmt de bastante importância, já que se encarrega de todos os documentos Internet-approved(ou seja, encarrega-se dos padrões estabelecidos), como é 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ão objectos geridos da MIB-I e MIB-II. Estas duas MIBs são as MIB de gestão de sistemas numa rede por excelência, ou seja, englobam as informações e tarefas de gestão 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ção e implementação dos OID, e esses grupos eram System, Interfaces, Address Translation, IP, ICMP, TCP, UDP, e EGP, em 1991 a MIB-II substituiu a MIB-I. 1.7 Operações SNMP O SNMP inclui um conjunto de comandos de gestão e respostas que permitem efectuar as operações de gestão. Maior parte das operações SNMP são executadas pelo gestor. As operações executadas pelos agentes são apenas operações de notificação. Uma operação SNMP compreende a execução de um ou mais comandos SNMP que podem ou não ter respostas associadas. Os agentes e os gestores usam a seguinte estrutura para o PDU(Protocol Data Unit): Conteúdo Versão do SNMP palavra chave de comunidade(community string) Um ou mais PDUs SNMP PDU SNMP Request ID (número de sequência) Error Status Error Index (se 0 indica o índice do OID que causou o erro) Lista de OIDs e valores Trap PDU Valores são Null para gets Enterprise (tipo de objecto que originou a trap) Agent address(endereço 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árias operações do SNMP, vão ser referidos alguns comandos que fazem parte dum pacote de software que dá pelo nome de Net-SNMP, anteriormente conhecido por UCD-SNMP. 8

Figura 4: Operação Get 1.7.1 get Esta operação é iniciada pelo NMS que envia um pedido ao agente. O agente recebe o pedido e processa-o, pode haver a possibilidade de não ser possível responder ao pedido, nesta situação 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ção que necessita através do OID, ou seja o identificador do objecto. Um exemplo do comando correspondente a esta operação é o snmpget(do pacote net-snmp), que recebe como argumentos o endereço 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ão definidos como tabelas em vez de um 0 coloca-se o número da linha que se pretende. Esta operação permite obter informação de apenas um objecto MIB. 1.7.2 get-next A operação get-next permite recolher um conjunto de valores de uma MIB, enviando uma série de comandos. Ou seja, por cada objecto MIB que queremos recolher, os comandos get-next e getresponse são gerados. O comando get-next percorre uma árvore por ordem lexicográfica. Visto que o OID é uma sequência de inteiros é fácil para uma agente começar na raíz da sua árvore de objectos e percorrer os objectos até 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é receber um erro do agente, este erro significa que se chegou ao fim da MIB, ou seja, já não há mais objectos para percorrer. Um exemplo de um comando de unix do pacote net-snmp que usa esta operação é o snmpwalk. Este comando é invocado da mesma maneira que o snmpget mas em vez de se especificar o OID, basta especificar o ramo da árvore 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 9

A sequência get-next retorna 7 variáveis MIB. Cada um destes objectos faz parte do grupo system como está definido no RFC 1213. Como referido acima o get-next é funciona com base na ordenação lexicográfica da árvore de objectos MIB. Assim dado um nome de um grupo, neste caso o system, o agente começa na raíz e percorre a árvore usando um procedimento semelhante a uma procura de profundidade-primeiro. Figura 5: Operação Get-next 1.7.3 get-bulk(snmpv2 e SNMPv3) A operação get-bulk foi introduzida pelo versão 2 do SNMP. Esta operação permite à aplicação de gestão recolher uma secção de uma tabela de uma só vez. O operação get pode tentar recolher mais de um objecto de uma só vez, mas o tamanho das mensagens é limitado pela capacidade do agente. Se o agente não conseguir enviar toda a informação que a aplicação de gestão pediu, então dá um erro e não envia nenhuns dados. A operação get-bulk por outro lado diz ao agente para ele apenas enviara a quantidade de informação máxima que conseguir. Isto significa ser possível obter informação incompleta. A operação get-bulk usa dois campos; não-repetidos e repetições-máximas, para proceder à recolha de informação. O valor n de não-repetidos diz à operação get-bulk que a informação dos primeiros n objectos pode ser recolhida usando uma operação get-next. O valor m de repetições-máximas diz à operação get-bulk para tentar até m operações get-next para recolher informação dos restantes objectos. Um exemplo de um comando unix que usa esta operação é 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ção do comando está ser pedida informação de três objectos, o número total de valores que vamos obter é dado pelo fórmula n + (m * r), em que n é o número de não-repetidos, que pode ser visto como o número de objectos escalares(objectos com apenas um valor) no pedido, neste caso vai ser 1 já que o único objecto escalar é o sysdescr, m é o número de repetiçõesmáximas, que neste caso é arbitrariamente 3, e r é o número de objectos não escalares no pedido, que neste caso são 2, ifinoctets e ifoutoctets, o que dá um resultado de 1+(3*2)=7, que é o número total valores que vamos obter. Como esta operação não está definida na versão 1 do SNMP é pois necessário especificar a versão do SNMP que queremos usar na chamada do comando com a opção -v2c. Os valores não-repetidos e repetições-máximas são especificados respectivamente usando a opção -B 1 3. 1.7.4 set A operação set é usada para mudar o valor de um objecto gerido, ou para criar uma nova linha numa tabela. Só os objectos que forem definidos como read-write e write-only podem ser alterados ou criados usando o set. É possível a um NMS fazer set a mais do que um objecto ao mesmo tempo. Figura 6: Operação Set Para exemplificar o uso desta operação 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ço de agente (cisco.ora.com), a identificação 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á 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ções provoca mensagens erro de resposta. As mensagens resposta de erro da versão SNMPv1 são as indicadas na tabela 3. Estas mensagens de erro contudo não são muito robustas. Para resolver este problema a versão SNMPv2 define mensagens reposta de erro adicionais que são válidas para as seguintes operações: 11

Nome da mensagem noerror(0) toobig(1) nosuchname(2) badvalue(3) readonly(4) generr(5) Descrição A operação foi executada com sucesso. A resposta ao pedido é demasiado grande para caber numa resposta. Não foi encontrado nenhum objecto com o OID especificado. Um objecto read-write ou write-only foi mudado para um valor inconsistente. Este erro geralmente não é utilizado. É equivalente ao erro no- SuchName. Este erro é gerado sempre que o erro que ocorre não corresponde a nenhum dos erros acima especificados. Tabela 3: Mensagens resposta de erro da versão SNMPv1 get, set, get-next, e get-bulk. Contudo é necessário que quer agente quer NMS suportem a versão 2 do SNMP. Na tabela 4 estão as mensagens resposta de erro que foram introduzidas pela versão 2 do SNMP. 1.7.6 trap Uma trap é uma notificação assíncrona do agente para o NMS, este tipo de notificação são usadas para informar o NMS que houve uma alteração no agente. Figura 7: Operação Trap O agente possui na sua configuração o endereço para onde deve enviar as traps que normalmente está associado a um NMS. Os NMS não respondem a traps. Visto que o SNMP usa UDP e que as traps foram desenhadas para encontrar problemas na rede, é fácil uma trap não chegar ao destino. No entanto esta operação não deixa de ter uma grande utilidade, porque mais vale o agente tentar comunicar o problema ao NMS do que simplesmente não ter nenhuma reacção. Algumas das situações que podem ser comunicadas por traps. Uma interface de rede do dispositivo perdeu a ligação à rede Uma interface de rede do dispositivo recuperou a ligação à rede Tentativa de estabelecimento de uma comunicação com um modem rack falhou. A ventoinha de um switch ou router deixou de funcionar. Estes são apenas algumas das situações. Quando um NMS recebe uma trap este precisa de saber o que significa e a informação que contém. Uma trap é identificada pelo identificador genérico de traps há 7 números de traps genéricas(0-6). Os vários tipos de traps estão descritos na tabela 5. A trap genérica 6 engloba 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) Descrição Houve uma tentativa de mudar um valor inacessível. Isto acontece quando a variável tem um tipo de ACCESS de not-accessible. Um objecto foi actualizado com um valor que não 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 é de tipo INTEGER por uma string. O valor do objecto foi mudado por um valor que não corresponde exactamente à especificação do objecto. Por exemplo, uma string pode ser definida para ter um número máximo 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ção errada. Uma variável foi substituída por um valor que não percebe. Este erro ocorre, por exemplo, quando um objecto é definido com uma enumeração e o tipo do valor com que se tentou substituir o valor do objecto, não corresponde a nenhum dos tipos enumerados. O objecto de que se tentou mudar o valor não está definido na MIB. Um objecto está inconsistente e portanto não aceita novos valores. Não há recursos no sistema para executar o pedido. Uma mensagem de resposta é enviada com este erro, sempre que uma operação de set falha. A operação de set falhou e o agente não conseguiu repor os valores que foram mudados antes a operação falhar. Um comando SNMP não pode ser autenticado, ou seja, palavra chave de comunidade errada. O objecto não aceita uma operação de set, apesar de ser suposto aceitar. Houve uma tentativa de efectuar set a uma variável, mas esta falhou porque a variável se encontra num estado qualquer de inconsistência. Tabela 4: Mensagens resposta de erro que foram introduzidas pela versão 2 do SNMP 13

Tipo de trap Descrição coldstart(0) Indica que o agente reinicializou o sistema. Todas as variáveis de gestão vão ser reinicializadas. Este tipo de trap pode ser usado para determinar quando foi adicionado novo hardware à rede. Quando um dispositivo é ligado envia uma traps deste tipo. warmstart(1) Indica que o agente se reinicializou. As variáveis de gestão não foram reinicializadas. linkdown(2) Esta trap é enviada quando uma interface do dispositivo perde a ligação à rede. O primeiro par objecto valor identifica a interface. linkup(3) Esta trap é enviada quando uma interface do dispositivo recupera a ligação à rede. O primeiro par objecto valor identifica a interface. authenticationfailure (4) Indica que alguém tentou recolher informação do agente com uma palavra chave de comunidade errada. egpneighborloss (5) Indica que se perdeu a ligação a um vizinho EGP(Exterior Gateway Protocol). enterprisespecific (6) Indica que a trap é uma entreprise-specific trap. Para processar esta trap o NMS tem de descodificar o número que especifica a trap, que faz parte da mensagem SNMP. Tabela 5: tipos de traps da versão SNMPv1 todas as traps que não são as 0-5. As traps que não se enquadram nas traps 0-5 são as chamadas entreprise-specific traps, que são traps definidas por fabricantes de hardware ou utilizadores, estas traps são identificadas pelo enterprise ID(identificação do objecto algures no ramo enterprises da MIB) e um número de trap escolhido pelo fabricante ou utilizador. As traps contém informação em forma de objectos MIB. Para as traps 0-5 o conhecimento do que a trap significa está embebido no NMS ou no software que recebe as traps. Os objectos e respectivos valores das enterprise-specific traps são determinados por quem definiu a trap. Um exemplo de uma definição de uma enterprise trap é a rdbmsoutofspace que é 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 é rdbmstraps o número da trap é 2. Esta trap contém o valor da variável rdbmssrvinfodiskoutofspaces cuja definição é 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ão consegue alocar espaço 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êm um formato PDU diferente das operações get e set) a versão SNMPv2 introduz o tipo NOTIFICATION- TYPE. O formato PDU é idêntico ao do formato PDU das operações get e set. Assim a definição das traps é feita de maneira diferente, um exemplo é a definição do tipo notificação genérica 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 condição de linkdown para outra qualquer condição. 1.7.8 inform(snmpv2 e SNMPv3) A versão SNMPv2 introduziu uma nova operação chamada inform, esta operação permite comunicação gestor para gestor. Esta operação é útil quando há a necessidade de existirem vários gestores numa rede. Quando uma mensagem inform é enviada de gestor para outro o receptor envia uma resposta que informa que a mensagem foi recebida. Esta operação também pode ser usada par enviar traps SNMPv2 para um NMS, o que permite ao agente receber uma notificação quando o NMS recebe a trap. 1.7.9 report(snmpv2 e SNMPv3) Esta operação foi definida para a versão SNMPv2 mas nunca foi implementada nesta versão. Contudo faz parte da versão 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ão definidos nos RFC 2819 e 2021 respectivamente. A versão 1 do RMON fornece ao NMS estatísticas a nível de pacotes de toda a rede LAN ou WAN. A versão 2 do RMON adiciona estatísticas a nível da rede a de aplicações, à versão 1 do RMON. Estas estatísticas podem ser recolhidas de várias maneiras. Uma delas é 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 à sonda recolher estatísticas da rede que monitoriza sem ser necessário que um NMS esteja constantemente a pedir informação. A qualquer altura o NMS pode requerer as estatísticas que a sonda tem vindo a recolher. Outra das funcionalidades que é possível atribuir às sondas 15

RMON, é definir valores que quando atingidos ou ultrapassados provoquem o envio de traps ao NMS. A MIB RMONv1 define os seguintes grupos. rmon OBJECT IDENTIFIER ::= { mib-2 16 } statistics OBJECT IDENTIFIER ::= { rmon 1 } history OBJECT IDENTIFIER ::= { rmon 2 } alarm OBJECT IDENTIFIER ::= { rmon 3 } hosts OBJECT IDENTIFIER ::= { rmon 4 } hosttopn OBJECT IDENTIFIER ::= { rmon 5 } matrix OBJECT IDENTIFIER ::= { rmon 6 } filter OBJECT IDENTIFIER ::= { rmon 7 } capture OBJECT IDENTIFIER ::= { rmon 8 } event OBJECT IDENTIFIER ::= { rmon 9 } Como referido acima, estes objectos referem-se a estatísticas a nível de pacotes. RMONv2 define mais objectos. A MIB 2 Objectivos do trabalho e da demonstração Dada as potencialidades deste protocolo e sabendo que o seu uso na gestão de redes grandes facilita e muito a tarefa de uma equipa de gestão de redes, tentou-se dar uma ideia daquilo que é possível fazer com este protocolo. Tendo isto em mente tentou-se analisar algumas opções de software livre que fazem uso deste protocolo para gestão de redes. Existem peças de sofware complexas que tentam reunir todas as tarefas de gestão num sistema com vista a ser possível uma administração centralizada, essas peças de software que são conhecidas 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 utilizações 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é às suites profissionais, de produtos de código aberto a software proprietário 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ém conhecido por Gnome Snmp. Contem um construtor para a interface de gestão. O mais popular em Linux. O mais fácil de personalizar. Tabela 6: NMS s de código aberto Hp OpenView IBM Tivoli Netview BMC CA Unicenter Advetnet OptManager Familia SNMP da HP; Muito usada. A solução da IBM; Vocacionada para o B2B. Solução da Castle Rock.Tabém muito usada. Especializada para sistemas unix. Com uma interface espectacular;difícil de Instalar. Tabela 7: NMS s proprietários Agentes no Linux: Existe uma variedade de gestores para máquinas Linux. Quase todas as suites NMS referidas anteriormente comportam um agente a instalar nas máquinas a gerir/monitorizar. Como o SNMP é 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 suportam SNMP vem com um agente que pode ser configurado de modo a trabalhar com os gestores. De referir também que em Linux ao contrário do Windows o gestores SNMP padrão não são parte integrante do kernel. Assim não 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ça. 3 Avaliação do SNMP através de algumas peças de software SNMP 3.1 NetSNMP Como gestores das máquinas Linux escolhemos os o Net-snmp pois é de código-aberto, gratuito e extremamente robusto. A comunidade aceita também o net-snmp como o agente SNMP padrão em redes Linux. O Net-SNMP é um pacote de software que inclui: Um agente extensível Uma biblioteca para desenvolvimento (c/python/perl). Utilitários para trocar informação com os agentes (request/set). Utilitários para gerar e tratar traps (generate/handle). Utilitários que reimplementam os conhecidos utilitários unix df e netstat numa versão SNMP. Um Tk/perl MIB Browser Ps: No anexo 1 encontrará informação de como instalar e configurar o net-snmp. 3.2 OpenNMS O opennms é um NMS bastante complexo, feito em jsp este NMS não utiliza somente o protocolo SNMP para monitorização de redes. Este NMS usa alguns métodos para descobrir entidades de rede que são passíveis de serem geridas, que fazem uso de pedidos ICMP. Na secção OpenNMS está a análise deste software. 4 Processo experimental 4.1 A experiência Após consolidarmos vários conceitos fundamentais do SNMP, partimos para a sua análise em detalhe. Para tal montamos uma pequena rede com vários computadores pessoais, um hub e um routers a rede está exemplificada na figura 8. De seguida usando um programa de capturas de rede, analisámos as mensagens trocadas entre os vários agentes e gestores instalados e configurados nas máquinas ligadas à rede. 4.2 O software utilizado 4.2.1 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ós sua activação. 17

Figura 8: Diagrama da rede experimental 4.2.2 Gestores: Para podermos analisar o protocolo, o papel do gestor é executado através da linha de comandos usando os utilitários snmpget, snmpgetnext, snmpbulkget, snmpset e trapd disponibilizados pelo net-snmp. Experimentamos também posteriormente vários 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ém de permitir transformar qualquer terminal unix num agente SNMP, traz também um conjunto de programas que implementam as operações SNMP existentes. Este pacote foi usado para analisar o funcionamente do protocolo SNMP ao nível mais baixo, isto é, para analisar as operações SNMP. Com o objectivo de analisar as operações SNMP executou-se cada um dos comandos fornecidos pelo o pacote e procedeu-se à captura das mensagens trocados. As capturas efectuadas bem como uma pequena análise do comando, encontram-se na secção referente ao comando. 5.1 SNMP get Exemplo de uma operação 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