Anda di halaman 1dari 114

Jos Messias Alves da Silva

Construo de Agentes SNMP em Ambientes Linux


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

Anda mungkin juga menyukai