UNIVERSIDADE FEDERAL DE GOIÁS

ESCOLA DE ENGENHARIA ELÉTRICA E DE COMPUTAÇÃO

PROJETO FINAL DE CURSO

ANÁLISE DE PROTOCOLOS NA ÁREA DE

GERÊNCIA DE REDES (SNMP/RMON)

Clayton Araújo Freitas

João Wesley Alves Monteiro
Orientador: Profº MSc. Carlos Galvão Pinheiro Jr.
 I

Goiânia
2004
CLAYTON ARAÚJO FREITAS
JOÃO WESLEY ALVES MONTEIRO

ANÁLISE DE PROTOCOLOS NA ÁREA DE GERÊNCIA DE

REDES (SNMP/RMON)

Projeto final apresentado ao Curso de

Graduação em Engenharia de Computação da
Universidade de Goiás, para obtenção do
título de Engenheiro de Computação.
Área de concentração: Gerência de Redes.
Orientador: Profº Carlos Galvão Pinheiro Jr.
 II

Goiânia
2004
CLAYTON ARAÚJO FREITAS
JOÃO WESLEY ALVES MONTEIRO

ANÁLISE DE PROTOCOLOS NA ÁREA DE

GERÊNCIA DE REDES (SNMP/RMON)

Projeto final apresentado e aprovado em Dezesseis de

Janeiro de 2004, pela Banca Examinadora composta por:

______________________________________
Prof. MSc. Carlos Galvão Pinheiro Jr
Presidente da Banca

_______________________________________
Prof. Dr. Gelson da Cruz Jr

_______________________________________
Eng. Eletricista Alex da Rosa
 III

Dedicamos esse trabalho aos nossos pais, amigos e professores pelo

incentivo e apoio, sem os quais esta obra não se realizaria.
 IV

AGRADECIMENTOS

Ao professor e orientador deste projeto final de curso, Carlos Galvão Pinheiro Jr pelo
incentivo, motivação e flexibilidade no decorrer de todo o trabalho.
Aos nossos colegas de graduação Luciano de Oliveira Costa, Giscar Fernandes V.
de Paiva, pelo auxílio na obtenção de material para efetuar os nossos estudos.
Ao professor Ubaldo Eleutério da Silva, professor do CEFET-Goiás, que nos
ofereceu a oportunidade de acompanhar o seu projeto de mestrado na UNB, o qual serviu de
base para o nosso projeto final de curso.
Somos ainda, extremamente gratos àqueles que direta e indiretamente contribuíram
para a realização desse trabalho.
 V
SUMÁRIO

LISTA DE ABREVIATURAS-----------------------------------------------------------------------VII
LISTA DE FIGURAS--------------------------------------------------------------------------------VIII
LISTA DE TABELAS---------------------------------------------------------------------------------IX

RESUMO--------------------------------------------------------------------------------------------------X

INTRODUÇÃO-------------------------------------------------------------------------------------------11

CAPÍTULO 1–TEORIA SOBRE GERENCIAMENTO DE REDES------------------------13

1.1 TIPOS DE GERENCIAMENTO--------------------------------------------------------------14
1.1.1 GERENCIAMENTO DE FALHAS-----------------------------------------------------------14
1.1.2 GERENCIAMENTO DE CONTABILIDADE----------------------------------------------15
1.1.3 GERENCIAMENTO DE CONFIGURAÇÃO-----------------------------------------------15
1.1.4 GERENCIAMENTO DE DESEMPENHO--------------------------------------------------16
1.1.5 GERENCIAMENTO DE SEGURANÇA---------------------------------------------------16
1.2 AXIOMAS DE GERENCIAMENTO DE REDES---------------------------------------------17

CAPÍTULO 2–SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)-----------20

2.1 HISTÓRICO DA GERÊNCIA DE REDES TCP/IP--------------------------------------21
2.2 DESENVOLVIMENTO DO SNMP------------------------------------------------------25
2.3 ARQUITETURAS DE GERENCIAMENTO--------------------------------------------30
2.4 O MODELO DE GERENCIAMENTO DA INTERNET-------------------------------33
2.5 DEFINIÇÃO DOS RELACIONAMENTOS ADMINISTRATIVOS----------------35
2.6 OPERAÇÕES SNMP------------------------------------------------------------------------37
2.7 FORMATO DAS MENSAGENS SNMP-------------------------------------------------39
2.8 PROXIES-------------------------------------------------------------------------------------41
2.9 AS VANTAGENS DO SNMP-------------------------------------------------------------42
2.10 AS DESVANTAGENS DO SNMP-----------------------------------------------43
2.11 MÉTODOS DE IMPLEMENTAÇÃO----------------------------------------------44
2.12 CONSTRUÇÃO DE AGENTES SNMP-------------------------------------------44
2.12.1 TÉCNICAS DE CONSTRUÇÃO USANDO SOCKETS--------------------45
2.12.2 TÉCNICAS DE CONSTRUÇÃO USANDO PROXY-----------------------46
2.12.3 TÉCNICAS DE CONSTRUÇÃO USANDO AGENTE ESTENDIDO---46
 VI

CAPÍTULO 3 – RMON (REMOTE MONITORING)----------------------------------------47

3.1 OBJETIVOS DO PROTOCOLO RMON--------------------------------------------------49
3.1.1 CONTROLE DE MONITORES REMOTOS-------------------------------------50
3.1. 2 MÚLTIPLOS GERENTES---------------------------------------------------------51
3.2 RMON1 E RMON2-------------------------------------------------------------------------52
3.3 REMOTE MONITORING INFORMATION BASE (RMON-MIB)----------------53
3.3.1 GRUPOS DA RMON1-MIB-----------------------------------------------------53
3.3.2 GRUPOS DA RMON2-MIB-----------------------------------------------------54
3.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON----------------------------------55

CAPÍTULO 4 – MANAGEMENT INFORMATION BASE (MIB)------------------------56

4.1 ESTRUTURA DA MIB--------------------------------------------------------------------58
4.2 DEFINIÇÃO DE OBJETOS---------------------------------------------------------------62
4.3 DEFINIÇÕES PARA SMI-----------------------------------------------------------------62

CAPÍTULO 5 – ESTUDO DE CASO-------------------------------------------------------------65

5.1 APLICAÇÃO COM CLP------------------------------------------------------------------66
5.2 ARQUITETURA DE UM CLP-----------------------------------------------------------66
5.3 PROPOSTA DE MIB----------------------------------------------------------------------66
5.4 TRAPS---------------------------------------------------------------------------------------67
5.5 ALTERNATIVAS DE IMPLEMENTAÇÃO DO AGENTE-----------------------67
5.5.1 AGENTE NO PRÓPRIO CLP-------------------------------------------------67
5.5.2 AGENTE COMO UM PROXY-----------------------------------------------68
5.6 IMPLEMENTAÇÃO DO SOFTWARE AGENTE----------------------------------69
5.7 OBSERVAÇÕES LEVANTADAS------------------------------------------------------70
CAPÍTULO 6 – SOFTWARES DE GERENCIAMENTO-----------------------------------------71
6.1 O PAPEL DOS SOFTWARES DE GERENCIMENTO-------------------------------72
6.2 PLATAFORMAS DE GERENCIAMENTO--------------------------------------------72
6.3 O PROJETO FREENMS------------------------------------------------------------------73
6.4 MRTG (MULTI ROUTER TRAFFIC GRAPHER)------------------------------------75
6.5 WHATSUP----------------------------------------------------------------------------------77
CONCLUSÃO--------------------------------------------------------------------------------------------84

REFERÊNCIAS BIBLIOGRÁFICAS----------------------------------------------------------------75
 VII
Lista de Abreviaturas
API - Aplication Programming Interface
CLP - Controlador Lógico Programável
CMOT - CMIP (Common management Information Protocol) over TCP/IP
DOD - Departament of Defense
FreeNMS - Free Network Management System
IAB - Internet Architecture Board
ICMP - Internet Control Message Protocol
IETF - Internet Engineering Task Force
LAN - Local Area Network
MIB - Management Information Base
MRTG - Multi Router Grapher
OID - Object Identifier
OSI - Open Systems Interconnection
PDU - Protocol Data Unit
QoS - Quality of Service
ReMAV - Redes Metropolitanas de Alta Velocidade
RFC - Request For Comment
RMON - Remote Monitoring
SGRI - Sistema de Gerenciamento de Redes Integradas
SLA - Service Level Agreement
SMI - Structure of Management Information
SMP - Simple Management Protocol
SNMP - Simple Network Management Protocol
SNMPv2c - Simple Network Management Protocol version 2 Community Based
SNMPv3 - Simple Network Management Protocol version 3
TCP - Transmission Control Protocol
TCP/IP - Transmission Control Protocol/ Internet Protocol
UDP - User Datagram Protocol
WAN - Wide Area Network
 VIII
Lista de Figuras

Figura 1.2.1 Sistema de gerenciamento SNMP----------------------------------------------------19

Figura 2.2.1 Arquitetura do protocolo SNMPv3--------------------------------------------------29

Figura 2.3.1 Possível configuração de sistema com SNMP-------------------------------------32

Figura 2.7.1 Formato das mensagens SNMP------------------------------------------------------39

Figura 2.8.1 Gerenciamento utilizando o conceito de proxy------------------------------------42

Figura 2.12.1 Uso de agentes extensivos/estendidos-----------------------------------------------45

Figura 2.12.2 Uso dos sockets-------------------------------------------------------------------------46

Figura 2.12.3 Uso do agente estendido---------------------------------------------------------------46

Figura 4.1.1 Árvore da MIB construída pelo MIB Browser------------------------------------58

Figura 5.5.1 Agente implementado no controlador----------------------------------------------67

Figura 5.5.2 Implementação usando a pilha TCP/IP---------------------------------------------67

Figura 5.5.3 Implementação com agente do tipo proxy-----------------------------------------68

Figura 5.6.1 Módulos usados para interfacear com o CLP-------------------------------------69

Figura 6.4.1 Gráfico gerado pelo MRTG---------------------------------------------------------76

Figura 6.5.1 Guia Geral-----------------------------------------------------------------------------78

Figura 6.5.2 Guia SNMP----------------------------------------------------------------------------78

Figura 6.5.3 Guia Monitor--------------------------------------------------------------------------79

Figura 6.5.4 Guia Services--------------------------------------------------------------------------80

Figura 6.5.5 Guia Alerts----------------------------------------------------------------------------80

Figura 6.5.6 Guia Notes-----------------------------------------------------------------------------81

Figura 6.5.7 Guia Menu-----------------------------------------------------------------------------82

 IX
LISTA DE TABELAS

Tabela 1 RFCs relacionadas ao gerenciamento de redes no TCP/IP-------------------------------26

Tabela 2 RFCs relacionadas ao SNMPv2c------------------------------------------------------------28

Tabela 3 RFCs relacionadas ao SNMPv3------------------------------- ------------------------------29

Tabela 4 Formato das mensagens utilizadas no SNMP----------------------------------------------40

Tabela 5 Grupos estudados na MIB--------------------------------------------------------------------60

Tabela 6 Softwares de gerenciamento SNMP/RMON-----------------------------------------------83

 X

RESUMO

Com o objetivo de garantir a qualidade do serviço de redes para os diversos

tipos de usuários, foi necessário ampliar as ferramentas de supervisão de rede,
favorecendo a agilidade, produtividade, segurança e portabilidade nas operações.
Sendo assim, este trabalho apresenta um estudo sobre a origem,
desenvolvimento e utilização de protocolos de gerência, em específico: SNMP e
RMON. Além disso, discutimos alguns aplicativos que utilizam estes protocolos.
Discutimos brevemente o projeto FreeNMS que está sendo desenvolvido
atualmente na PUCRS e que tem como alvo empresas que buscam melhorias na
performance das suas redes, sobretudo na qualidade de serviço.
Nesse trabalho é apresentado um estudo que vai de encontro com os anseios da
indústria: aplicação do SNMP utilizando ferramentas de um controlador lógico-
programável (CLP).
 INTRODUÇÃO
As redes de computadores e sistemas distribuídos estão se tornando cada vez mais
importantes dentro das organizações comerciais, governamentais e institucionais. Para
essas organizações, os recursos disponibilizados pela rede e suas aplicações suportadas são
indispensáveis, embora problemas ocorram seguidamente. A detecção dos problemas e a
administração de todos os recursos são tarefas complexas, que demandam grandes esforços
dos gerentes e administradores de rede. Desta forma, são fundamentais as ferramentas
computacionais que auxiliem na gerência e administração das redes.
Essas ferramentas se baseiam na arquitetura gerente/agente, onde o gerente envia
requisições ao agente, que atua diretamente nos recursos gerenciados. Este ciclo de
gerência pode ser resumido em observação (recuperar valores e eventos) e controle (gerar
eventos e alterar valores). As interfaces pelas quais o administrador realizará essas ações, a
partir da estação gerente, são de extrema importância, sendo, geralmente, orientadas a texto
ou gráficos bidimensionais.
Este trabalho de projeto final tem como objetivo propor um estudo dos protocolos
de Gerência de Redes, especificamente o SNMP e o RMON.
Alguns passos a serem seguidos no decorrer deste trabalho são o estudo do estado
da arte em gerência de rede protocolo SNMP (Simple Network Management Protocol),
base de gerência MIB-II (Management Information Base II) e o protocolo RMON (Remote
Network Monitoring) e a elaboração do texto.
Quando a rede ARPANET se tornou a rede mundial, com a interconexão de
equipamentos heterogêneos cada vez mais comuns, ferramentas de gerência padrões se
tornaram necessárias. Até aquele momento, quando alguma atividade de gerência era
necessária, o gerente deveria ir até o equipamento relevante e realizar algum tipo de teste
diretamente nele, ou através de ferramentas proprietárias, fazer alguma operação
remotamente. Mas as ferramentas proprietárias eram úteis somente para um certo
equipamento de certos fabricantes, não se aplicando num contexto geral. E ter que ir
pessoalmente aos equipamentos era inviável, visto que a rede crescia continuamente.
Então algumas RFCs (Request For Comment) foram propostas ao IAB (Internet
Architecture Board) sem muito êxito, até que a RFC 1157, de 1990, propôs o protocolo
SNMP (Simple Network Management Protocol), mais tarde amplamente adotado como
padrão de gerência em redes TCP/IP (Transmission Control Protocol /Internet Protocol).
 12
Não tendo muitas ambições, o protocolo deveria ser simples e suportar operações simples,
baseado na arquitetura cliente/servidor, ou especificamente, gerente/agente.
O dispositivo que contém o gerente, localizado numa máquina que ofereça um certo
poder de processamento, memória e interface, tem o aplicativo pelo qual o operador
humano usará o protocolo. O software gerente envia comandos de leitura ou
armazenamento ao agente, que tem como única operação dar a devida resposta ao
requisitante. Segundo esse paradigma, a tarefa de gerência de rede se baseia em duas ações
típicas: observação e controle à distância.
Desta forma, a interface do gerente é decisiva e importante. Assim como as tarefas
foram se tornando complexas, a exigência por efetivamente visualizar, monitorar e
manipular os recursos gerenciados se torna essencial. As interfaces foram se tornando
gráficas, o uso de ícones que representavam os diversos equipamentos (ícones para
estações, para hubs, roteadores) auxiliava na identificação rápida dos equipamentos. Logo
imagens mais realísticas passaram a serem usadas, quase representando imagens
fotográficas dos equipamentos.
O objetivo desta pesquisa é fazer um estudo sobre a gerência de rede, contemplando
o interfaceamento mais realístico do operador humano com equipamentos remotos, como
se estivesse local a eles, com ênfase às ações manifestadas em operações do protocolo
SNMP e RMON.
Desta maneira, alguns objetivos intermediários são:
9 Estudo do estado da arte em gerência de rede;
9 Estudo do protocolo SNMP e das MIB II, e RMON e MIBs.
Utilizou-se para este trabalho uma metodologia que consiste na identificação do
contexto, estudando as tecnologias envolvidas para o SNMP, para as MIBS, e para o
RMON.
Foi feita ainda, uma pesquisa sobre a manipulação dos objetos gerenciáveis,
utilizando os protocolos SNMP e RMON, para permitir a interação entre eles na rede.
 13

CAPÍTULO 1

TEORIA SOBRE GERENCIAMENTO DE REDES

No capítulo 1, tem-se uma abordagem acerca da teoria que abrange a

gerência de redes, estudando as suas subclasses. Serão discutidos os axiomas
da gerência de redes, tendo os passos básicos para operar eficazmente no
processo. São definidos, também, os componentes básicos de um sistema que
utiliza o SNMP, tais como o Gerente e o Agente.
 14
O contínuo crescimento em número e diversidade dos componentes das redes de
computadores tem tornado a atividade de gerenciamento da rede cada vez mais complexa.
Duas causas principais têm tornado árduo o trabalho de isolamento e teste de problemas:
9 Diversidade dos níveis do pessoal envolvido: técnicos, gerentes e
engenheiros;
9 Diversidade nas formas de controle e monitoração: produtos cada vez mais
complexos, cada fornecedor oferecendo ferramentas próprias de controle e monitoração.
Para expandir melhor os meios de pesquisa e atuação na área de gerência, a ISO
dividiu o gerenciamento de redes em cinco áreas funcionais:
9 Gerenciamento de falhas;
9 Gerenciamento de configuração;
9 Gerenciamento de segurança;
9 Gerenciamento de performance e
9 Gerenciamento de contabilização.
Muitas vezes as áreas funcionais possuem funções de gerenciamento que se
sobrepõem, isto é, são utilizadas não somente uma, mas até mesmo em várias áreas de
gerenciamento, apesar de terem finalidades em cada uma. Por outro lado, algumas funções
servem de suporte para as funções das outras áreas.

1.1 TIPOS DE GERENCIAMENTO

1.1.1 GERENCIAMENTO DE FALHAS
A gerência de falhas tem a responsabilidade de monitorar os estados dos recursos,
dar manutenção a cada um dos objetos gerenciados, e tomar decisões para restabelecer as
unidades do sistema que venham a dar problemas.
As informações que são coletadas sobre os vários recursos da rede podem ser
usadas em conjunto com um mapa desta rede, para indicar quais elementos estão
funcionando, quais estão em mau funcionamento, e quais não estão funcionado.
Opcionalmente, pode-se gerar um registro das ocorrências na rede, um diagnóstico
das falhas ocorridas e uma relação dos resultados deste diagnóstico com as ações
posteriores a serem tomadas para o reparo dos objetos que geraram as falhas.
O ideal é que as falhas sejam detectadas antes que os efeitos prejudiciais,
decorrentes destas, possam vir a acontecer. Pode-se conseguir este ideal através do
 15
monitoramento das taxas de erros do sistema, e da evolução do nível de severidade gerado
pelos alarmes (função de relatório alarme), que permitem a emissão das notificações de
alarme ao gerente, que pode definir as ações necessárias para corrigir o problema e evitar
as situações mais críticas.

1.1.2 GERENCIAMENTO DE CONTABILIDADE

O gerenciamento de contabilidade possibilita estabelecerem-se as taxas a serem

utilizadas pelos recursos no ambiente OSI e os custos a serem identificados na utilização
daqueles recursos. Outras considerações incluem informações dos custos dos usuários e
recursos gastos, estipulando limites e incorporando informações de tarifas em todo o
processo de contabilidade.
No mundo de hoje, contabilidade significa tratar com pessoas usando os reais
recursos de rede com despesas de operação real. Exemplos destes custos incluem uso do
espaço em disco e dados armazenados, despesas de telecomunicações para acesso a dados
remotos e taxas de envio de e-mail.
Pode-se também usar o gerenciamento de contabilidade para determinar se a
utilização dos recursos da rede estão aumentando com o crescimento, o que deve indicar a
necessidade de adições e reajustamentos num futuro próximo.

1.1.3 GERENCIAMENTO DE CONFIGURAÇÃO

O objetivo da gerência de configuração é o de permitir a preparação, a iniciação, a

partida, a operação contínua e a posterior suspensão dos serviços de interconexão entre os
sistemas abertos, tendo então, a função de manutenção e monitoramento da estrutura física
e lógica de uma rede, incluindo a verificação da existência dos componentes e a
verificação de interconectividade entre estes componentes.
A gerência de configuração é correspondente a um conjunto de facilidades que
permitem controlar os objetos gerenciados, identificá-los, coletar e disponibilizar dados
sobre estes objetos para as seguintes funções:
9 Atribuição de valores iniciais aos parâmetros de um sistema aberto;
9 Início e encerramento das operações sobre os objetos gerenciados;
 16
9 Alteração da configuração do sistema aberto e
9 Associação de nomes a conjuntos de objetos gerenciados.

1.1.4 GERENCIAMENTO DE DESEMPENHO

Na gerência de desempenho tem-se a possibilidade de avaliar-se o comportamento

dos recursos num ambiente de gerenciamento OSI para verificar se este comportamento é
eficiente, ou seja, preocupa-se com o desempenho corrente de rede, através de parâmetros
estatísticos como atrasos, vazão, disponibilidade e o número de retransmissões realizadas.
O gerenciamento de desempenho é um conjunto de funções responsáveis por
garantirem que não ocorram insuficiências de recursos quando sua utilização se aproximar
da capacidade total do sistema.
Para atingir estes objetivos, deve-se monitorar as taxas de utilização dos recursos,
as taxas em que estes recursos são pedidos e as taxas em que os pedidos a um recurso são
rejeitados. Para cada tipo de monitoramento, define-se um valor máximo aceitável
(threshold), um valor de alerta, e um valor em que se remove a situação de alerta.
Definem-se três modelos para atender aos requisitos de monitoramento de uso dos
recursos dos sistemas:
9 Modelo de Utilização: Provê o monitoramento do uso instantâneo de um
recurso;
9 Modelo de Rejeição: Provê o monitoramento da rejeição de um pedido de
um serviço e
9 Modelo de Taxa de Pedido de Recursos: Provê o monitoramento dos
pedidos do uso de recursos.

1.1.5 GERENCIAMENTO DE SEGURANÇA

O objetivo do gerenciamento de segurança é o de dar subsídios a aplicações de

políticas de segurança, que são essências para que uma rede baseada no modelo OSI seja
corretamente configurada, protegendo os objetos contra de acessos indevidos. Deve-se
providenciar um alarme ao gerente da rede sempre que se detectarem eventos relativos à
segurança do sistema.
 17
As informações de gerenciamento de segurança são armazenadas numa MIB
especial, a qual deve dar apoio as três categorias de atividades de gerenciamento de
segurança existentes. Esta MIB é chamada de SMIB (Security Management Information
Base).

1.2 AXIOMAS DE GERENCIAMENTO DE REDES

Existem dois axiomas que devem ser levados em conta quando se está projetando e
estabelecendo um ambiente de gerenciamento de redes:
9 O tráfego devido às informações de gerenciamento não deve aumentar
significativamente o tráfego da rede;
9 O agente de protocolo no dispositivo gerenciado, não deve aumentar
significativamente o resultado de processamento a ponto de prejudicar a função principal
daquele dispositivo.
Para se montar uma plataforma de gerenciamento de redes, é necessário observar
qual o pacote de softwares que oferece as funcionalidades básicas para gerenciamento de
vários dispositivos diferentes, tendo como objetivo, oferecer funcionalidades genéricas
para gerenciamento padrão dos vários dispositivos.
Adicionalmente se pode citar, como forma de componentes funcionais úteis à
plataforma de gerência o uso de ferramentas gráficas, uma API (Aplication Programming
Interface) de programação e segurança no sistema de gerenciamento. Como exemplos
destas plataformas, pode-se citar o NetManager, da Sun; o OpenView da HP; o NetView
da IBM e o TNG Unicenter, da Computer Associates.
A eficiência na realização destas tarefas está diretamente ligada à presença de
ferramentas que as automatizem e de pessoal qualificado. Atualmente existem no mercado
diversos tipos de ferramentas que auxiliam o administrador nas atividades de
gerenciamento. Estas ferramentas podem ser divididas em quatro categorias:
9 Ferramentas de nível físico, que detectam problemas em termos de cabos e
conexões de hardware;
9 Monitores de rede, que se conectam as redes monitorando o tráfego;
9 Analisadores de rede, que auxiliam no rastreamento e correção de
problemas encontrados nas redes;
 18
9 Sistemas de gerenciamento de redes, os quais permitem a monitoração e
controle de uma rede inteira a partir de um ponto central.
Dentre a gama de soluções possíveis para o gerenciamento de redes, uma das mais
usuais consiste em utilizar um computador que interage com os diversos componentes da
rede para deles extrair as informações necessárias ao seu gerenciamento.
Evidentemente é preciso montar um banco de dados, que será gerente da rede,
contendo informações necessárias para apoiar o diagnóstico e na busca de soluções para
problemas da rede. Isto envolve esforço para identificar, rastrear e resolver situações de
falhas.
Como o tempo de espera do usuário pelo restabelecimento do serviço deve ser o
menor possível, tudo isto deve ser feito eficientemente.
Os sistemas de gerenciamento de redes apresentam a vantagem de ter um conjunto
de ferramentas para análise e depuração da rede. Estes sistemas podem apresentar também
uma série de mecanismos que facilitam a identificação, notificação e registro de
problemas, como por exemplo:
9 Alarmes que indicam, através de mensagens ou bips de alerta,
anormalidades na rede;
9 Geração automática de relatórios contendo as informações coletadas;
9 Facilidades para integrar novas funções ao próprio sistema de
gerenciamento;
9 Geração de gráficos estatísticos em tempo real;
9 Apresentação gráfica da topologia das redes.
Esses são os passos básicos para poder escolher um sistema confiável e que
contribua para o gerenciamento de uma rede:
9 Fazer o inventário dos dispositivos gerenciáveis na rede;
9 Determinar a área funcional de gerenciamento;
9 Escolher as aplicações de gerência para os dispositivos;
9 Escolher a plataforma de gerenciamento de acordo com as aplicações
selecionadas.
Em redes IP, o sistema de gerenciamento segue o modelo gerente-agente, onde o
GERENTE é o próprio sistema de gerenciamento de toda a parte de configuração ligada às
aplicações e ao usuário, e o AGENTE é um software que deve ser instalado nos
 19
equipamentos gerenciados e que servem para armazenar a informação de gerenciamento
local e encaminhar essa informação ao GERENTE via SNMP (Simple Network
Management Protocol). Trocando em miúdos, a tarefa do agente é responder as
requisições feitas pelo gerente em relação ao equipamento no qual o agente está instalado.
Esta interação é viabilizada pelo protocolo de gerenciamento SNMP, o qual é como uma
linguagem comum utilizada exclusivamente para a troca de informações de gerenciamento.
Dessa forma, o gerente consegue conversar com qualquer máquina que fale SNMP,
independente do tipo de hardware e sistema operacional. O conjunto de informações ao
qual o gerente pode fazer requisições ou alterações é denominado de Management
Information Base (MIB). Para melhor compreensão, veja a Figura 1.2.1.

Figura 1.2.1 - Sistema de gerenciamento SNMP

O protocolo de gerenciamento SNMP constitui atualmente um padrão operacional

"de fato", e grande parte do seu sucesso se deve a sua simplicidade, sendo um protocolo
send/receive com apenas quatro operações. Outro aspecto importante é a sua capacidade de
gerenciar redes heterogêneas constituídas de diferentes tecnologias, protocolos e sistemas
operacionais. Dessa forma, o SNMP pode gerenciar, por exemplo, redes Ethernet, Token
Ring e FDDI, conectando IBM PCs, Apple Machintosh, estações de trabalho SUN e outros
tipos de computadores.
As aplicações de gerenciamento utilizam o SNMP para:
9 Fazer polling nos dispositivos de rede e coletar dados estatísticos para
análise em tempo real.
9 Receber um conjunto limitado de notificações de eventos significativos ou
mensagens trap, a qual informa sobre algum evento importante ocorrido.
9 Reconfigurar dispositivos de rede.
 20

CAPÍTULO 2

SNMP (SIMPLE NETWORK MANAGEMENT

PROTOCOL)

No presente capítulo será feita uma discussão a respeito das raízes históricas
que inspiraram o surgimento do SNMP, discutindo-se sua arquitetura,
formato do quadro de mensagens, além das vantagens e desvantagens. A
construção de Agentes também será debatida no contexto.
 21
2.1 HISTÓRICO DA GERÊNCIA DE REDES TCP/IP
De forma a fazer um breve histórico da gerência de redes em TCP/IP remonta-se às
origens do próprio TCP/IP.
A origem do TCP/IP foi um projeto, de 1969, do Departamento de Defesa dos
Estados Unidos (DoD). Tinha como objetivos estudar uma forma de aumentar o
compartilhamento de recursos computacionais numa rede e, além disso, buscavam uma
forma de comunicação mais confiável do que as vulneráveis linhas de cobre do sistema de
telefonia, isso como um resultado do auge da Guerra Fria, onde um dos aspectos que
amedrontavam os setores de defesa era a perda total de comunicações em virtude de um
ataque nuclear. Assim, para resolver esses problemas, o DoD reuniu suas pesquisas no
Advanced Research Projects Agency (ARPA) que teve como resultado a criação da
precursora da Internet, a ARPANET.
A ARPANET cresceu muito rapidamente, tendo inicialmente apenas poucas dezenas
de hosts e logo depois crescendo para centenas de hosts, acomodando milhares de
terminais e rapidamente ficou claro que um dos principais problemas da ARPANET seria a
interoperabilidade. Diferentes hosts de diferentes fabricantes deveriam ser conectados,
precisando de sistemas de suporte à troca de arquivos, interação entre os terminais e hosts.
O problema se tornou ainda maior quando a ARPANET se tornou o centro da
crescente Internet, uma coleção de LANs (Local Area Networks) e WANs (Wide Area
Networks).
De modo a resolver o problema da interoperabilidade, foi desenvolvido um
conjunto de protocolos padronizados, os quais, na década de 70, deram origem aos atuais
protocolos da pilha TCP/IP. Estes protocolos foram considerados como padrões oficiais
para o Internet Architecture Board (IAB) através de Requests For Comments (RFCs).
Finalmente, os protocolos fundamentais dessa pilha TCP/IP nasceram de padrões
utilizados em tecnologias militares.
O TCP/IP preencheu as exigências do DoD e se tornou o padrão dessa organização.
Um aspecto interessante e inesperado foi o crescimento do TCP/IP em aplicações não
militares. Este crescimento começou a se intensificar na metade da década de 80,
exatamente quando estavam sendo feitos esforços para desenvolver um consenso
internacional em torno dos protocolos desenvolvidos pelo OSI. Afirmava-se que o OSI se
tornaria o responsável pela completa interoperabilidade dos sistemas, mas o TCP/IP
 22
cresceu muito nos últimos anos e continuou crescendo a cada dia, ainda mais depois da
popularização da Internet.
O TCP/IP se tornou tão mais popular no meio comercial por vários motivos,
incluindo o fato de já ser um conjunto de protocolos maduros, já profundamente testados,
que provêem a interoperabilidade dos sistemas e com um alto nível de funcionalidade. Já o
OSI demorou demais para apresentar uma versão comercialmente funcional, tendo seu
desenvolvimento muito lento. Apesar dele apresentar uma funcionalidade muito mais rica
que o TCP/IP, ele se tornou complexo demais, deixando a sua implementação muito difícil
e com um grande overhead. Portanto exige-se mais para conseguir a interoperabilidade de
software com o OSI do que com o TCP/IP.
Durante o desenvolvimento do TCP/IP pouco se estava pensando em relação à
gerência da rede. Inicialmente apenas os desenvolvedores dos protocolos e programadores
utilizavam a rede, de um tamanho ainda bastante reduzido. Desta forma, caso algum
problema ocorresse, os poucos especialistas que existiam conseguiam, com poucas e
simples ferramentas, vasculhar a rede, descobrir e corrigir o problema.
Durante a década de 70 não foi desenvolvida nenhuma ferramenta, nem um
protocolo em especial para o gerenciamento da rede. O protocolo Internet Control
Message Protocol (ICMP) era a única “ferramenta” simples que era efetivamente utilizada
no início da Internet para a gerência da rede. Disponível em qualquer equipamento que
suporte IP, o ICMP permite que se enviem mensagens de controle de roteadores e hosts
para um host, de forma a fornecer alguma informação a respeito de problemas na rede.
Uma das características mais importantes para o gerenciamento de redes suportado pelo
ICMP é o de mensagens echo/echo-reply. O mecanismo dessas mensagens permite que se
descubra se é possível a comunicação entre duas entidades da rede, isto é conseguido
porque quando uma mensagem do tipo echo é recebida, a entidade é obrigada a retornar o
conteúdo da mensagem como uma mensagem do tipo echo-reply. Outro par de mensagens
útil é a time-stamp/time-stamp-reply, o qual fornece um mecanismo para verificar as
características de atraso na rede.
Estas mensagens ICMP podem ser utilizadas de forma a criar simples, mas
poderosas ferramentas. Um bom exemplo disso é o programa PING (Packet Internet
Groper). Usando o ICMP e mais algumas opções adicionais como o número de pedidos e o
número de tentativas de solicitação, o PING pode ter várias funções. Como exemplos tem-
 23
se: determinar se um equipamento de rede pode ser alcançado, verificar se uma rede pode
ser alcançada e verificar as operações entre um servidor e um host. O PING pode ser
utilizado para verificar a taxa de perda de pacotes em uma sub-rede, podendo desta forma
ajudar no isolamento de áreas de congestionamento e pontos de falha.
Até a década de 80, o PING e outras ferramentas também simples foram suficientes
para se conseguir gerenciar a rede. Mas a partir daí, o crescimento da Internet se tornou
exponencial e do desenvolvimento de novas e mais poderosas ferramentas de
gerenciamento se tornou essencial. O grande aumento do número de hosts na Internet
causou também um grande aumento na complexidade, com um número muito maior de
sub-redes, de entidades a serem gerenciadas e também entidades que têm responsabilidades
por gerenciar parte da Internet.
Desta forma, com uma rede com proporções cada vez maiores, era impossível
deixar a cargo de poucos o seu gerenciamento, e ainda com ferramentas simples. Era
necessário que se desenvolvesse um protocolo padronizado com mais funcionalidades que
o PING e ao mesmo tempo simples de ser aprendido e usado por uma grande variedade de
pessoas. O ponto de partida do desenvolvimento de ferramentas desse tipo foi o Simple
Gateway Monitoring Protocol (SGMP), de 1987. Com ele três outras abordagens surgiram:
9 High-Level Entity Management System (HEMS): generalização de um dos
primeiro protocolos de gerenciamento de rede usado na Internet o Host Monitoring
Protocol (HMP);
9 Simple Network Management Protocol (SNMP): surgiu como um
aperfeiçoamento do Simple Gateway Management Protocol (SGMP);
9 CMIP over TCP/IP (CMOT): tentativa de incorporar o máximo possível do
protocolo (CMIP – Commom Management Information Protocol), serviços e estrutura do
banco de dados padronizado pela ISO para o gerenciamento de rede.
No início de 1988, a IAB avaliou estas propostas e aprovou um adicional
desenvolvimento do SNMP como uma proposta de mais curto prazo do que o CMOT. Isto
porque se pensava que em um razoável período de tempo as redes TCP/IP seriam
substituídas por protocolos baseados no OSI e dessa forma não se queria investir por um
longo período de tempo em protocolos que seriam abandonados, assim, o SNMP teria
apenas as funcionalidades mínimas para suportar o gerenciamento das redes TCP/IP e
funcionar também como uma experiência na área da gerência de rede. O SNMP foi
 24
escolhido, em detrimento do HEMS que tinha muito mais funcionalidades, exatamente
pelo motivo de não se querer gastar esforço extra em uma arquitetura de rede que não
parecia ter continuidade. Já se o CMIP pudesse ser implementado sobre o TCP/IP, quando
finalmente as redes baseadas na pilha de protocolos OSI se tornassem populares, a
transição seria simples e rápida. De forma a solidificar essa estratégia, foi definido que
ambos os protocolos, CMOT e SNMP, usariam o mesmo banco de dados de objetos
gerenciados, ou seja, os mesmos conjuntos de variáveis de controle e de formatos de
dados, desta forma uma única estrutura das informações SMI (Structure of Management
Information) e base de informações MIB.
Entretanto, ficou claro que seria impraticável manter a compatibilidade de objetos
entre os dois protocolos. No gerenciamento OSI, os objetos são vistos como entidades
sofisticadas, com atributos, procedimentos associados, capacidade de notificação e outras
características complexas. Já no SNMP, para mantê-lo simples, os objetos não são
realmente o que se considera objeto do ponto de vista da orientação a objetos, mas são
apenas variáveis com algumas características básicas, como tipos de dados, se são somente
leitura ou tem acesso de escrita entre outras. Dessa forma foi decidido pela IAB, que a
idéia de uma SMI/MIB comum para os dois protocolos não era viável, e o
desenvolvimento do SNMP e CMOT poderia seguir independentemente.
O SNMP é um protocolo não orientado à conexão; nenhuma ação prévia é
necessária no envio de mensagens; nenhuma ação é necessária após as mensagens terem
sido enviadas. Isso tem como conseqüência a perda de garantia que as mensagens do
protocolo chegarão ao destino. Porém, na prática, a maioria das mensagens é entregue, e
aquelas que não são podem ser retransmitidas. Esta característica impõe mais robustez ao
sistema, visto que como não existe a preocupação com a orientação à conexão, nem o
gerente, nem o sistema gerenciado necessitam um do outro para operar.
O SNMP é um protocolo da camada de aplicação designado para facilitar a troca de
informações de gerenciamento entre dispositivos de rede. Usando os dados transportados
pelo SNMP, os administradores de rede podem gerenciar mais facilmente a performance
da rede, encontrar e solucionar problemas e planejar com mais precisão uma possível
expansão da rede.
Atualmente, o SNMP é o mais popular protocolo para gerenciamento de diversas
redes comerciais como as usadas em universidades, centros de pesquisas e provedores de
 25
acesso e de informações. Esta popularização se deve ao fato de que o SNMP é um
protocolo relativamente simples, porém suficientemente poderoso para resolver os difíceis
problemas apresentados quando se tenta gerenciar redes heterogêneas.

2.2 DESENVOLVIMENTO DO SNMP

Assim que se decidiu pela libertação do desenvolvimento do SNMP das amarras da
compatibilidade com o OSI, seu progresso foi similar ao do TCP/IP. Rapidamente o SNMP
se tornou disponível em vários equipamentos de vários fabricantes, tornando-se o
protocolo de gerenciamento da escolha da maioria dos usuários, sendo praticamente um
padrão. Enquanto o TCP/IP ignorava as predições referentes a sua curta vida e continuava
a crescer mais ferozmente ainda, também o SNMP parecia se tornar a escolha da maioria,
enquanto que o desenvolvimento da gerência de rede pelo OSI continuava atrasado.
O SNMP mais básico já está sendo usado em larga escala, praticamente todos os
fabricantes de computadores, estações de trabalho, pontes, roteadores, hubs, etc. oferecem
o básico SNMP. Segue ainda o trabalho em SNMP sobre OSI e outras pilhas de protocolos
não TCP/IP, além dos tantos avanços que se tem feito ao SNMP em várias direções.
Uma das inovações mais significativas pode-se afirmar que foi a criação da
capacidade de gerenciamento remoto para SNMP. O monitoramento remoto, ou RMON
(Remote Monitoring) tem em sua definição a especificação da forma de monitorar as sub-
redes como um nodo, e não apenas como equipamentos ou sub-redes individualmente. O
RMON é visto pelos usuários e fabricantes como uma extensão essencial do SNMP.
Além do RMON, várias extensões a MIB básica do SNMP têm sido criadas.
Algumas dessas extensões são independentes de fabricantes sendo padrões adotados
internacionalmente e que foram acrescentadas a MIB original, como por exemplo, Token
Ring e FDDI. Outras são informações especificas de certos fabricantes e são consideradas
extensões privadas da MIB. Estas extensões não acrescentam novas tecnologias ao SNMP,
são apenas incrementos no conjunto de informações que se pode ser obtido pelas MIBs. A
Tabela 1, abaixo, lista as RFCs que servem de base para o estudo do gerenciamento de
redes interligado ao protocolo TCP/IP.
 26

Tabela 1 - RFCs relacionadas ao gerenciamento de redes no TCP/IP

RFC Data Título

1155 Maio, 1990 Structure and Identification of Management Information
(SMI) for TCP/IP-based Internet
1157 Maio, 1990 A Simple Network Management Protocol (SNMP)
1212 Março, 1991 Concise MIB Definitions
1213 Março, 1991 Management Information Base for Network
Management of TCP/IP-based Internet: MIB-II
1643 Julho, 1994 Definition of Managed Objects for the Ethernet-like
Interface Types

Com o passar dos tempos, o SNMP acabou se tornando inadequado para certas
aplicações maiores e mais complexas. Apesar de ainda ser extremamente útil para um
grande número de aplicações, muitos desenvolvedores estavam entre um protocolo sem
muitas funcionalidades e inadequado para seus objetivos (SNMP) e outro ainda era apenas
um promessa (sistemas de gerenciamento do OSI).
O gerente deve satisfazer os direitos de cada um para que isso possa ser feito da
melhor maneira possível.
Um dos grandes problemas do SNMP é a segurança. Não existe forma de autenticar
a origem de uma mensagem SNMP. A existência do nome de comunidade não garante
absolutamente nada em matéria de segurança, visto que ela não é criptografada, qualquer
entidade poderia capturar um pacote e obter o nome de comunidade atualmente utilizado
pelo sistema. Devido a essa deficiência, muitos fabricantes decidiram por não implementar
a mensagem set, prevenindo a modificação de valores no equipamento gerenciado. Isto
diminuía ainda mais as já reduzidas capacidades do SNMP, tornando-se apenas uma
ferramenta de monitoramento. Então, para contornar esse problema, um conjunto de RFCs
foram lançadas a partir de julho de 1992 tentando definir um “secure SNMP”.
Entretanto, o SNMP seguro ainda possuía várias deficiências. Assim, nesse mesmo
ano, uma nova proposta surgiu, definida como Simple Management Protocol (SMP).
Vários avanços foram feitos em relação ao SNMP, são eles:
 27
9 O SNMP foi criado para a gerência de qualquer tipo de recurso e não
apenas para recursos de rede. Ele pode ser utilizado para o gerenciamento de aplicações, de
sistemas e comunicação gerente-gerente;
9 Manteve a simplicidade, permitindo que fossem criadas implementações
pequenas e rápidas. Ainda acrescentou-se a capacidade de se transferir uma grande
quantidade de informações de gerenciamento de uma vez;
9 Incorporou os recursos de segurança encontrados no SNMP seguro;
9 Foi projetado para ser executado sobre as pilhas de protocolo TCP/IP, e
outras arquiteturas de comunicação. Pode operar em conjunto com plataformas SNMP já
instaladas, utilizando apenas parte de seus recursos.
Após a publicação do SNMP seguro preferiu-se fazer uma única transição entre o
SNMP já existente e uma segunda versão do SNMP que incorporasse os avanços em
termos de funcionalidade e também os aspectos de segurança presentes no SNMP seguro e
no SMP. Grupos de trabalho foram criados, e em março de 1993 foi lançada a nova versão
do SNMP, denominada SNMPv2.
O SNMPv2 incorpora novas características e funcionalidades à versão anterior.
Quanto à definição da MIB e de sua estrutura, foram acrescentados novos tipos de dados,
como tipos inteiros com um maior número de bits. A macro que define os objetos da MIB
também foi estendida, e as cláusulas de TYPE-NOTATION e STATUS foram revisadas.
A versão 2 do SNMP manteve os tipos de pacotes da versão anterior e acrescentou
mais 3 novos pacotes: GetBulkRequest, InformRequest e Report.
A mensagem GetBulkRequest é utilizada para recuperar uma grande quantidade de
dados, sendo como um aperfeiçoamento ao GetNextRequest. Ela funciona como se fossem
executados vários GetNextRequest em uma única PDU, alterando apenas a sintaxe de dois
campos, o campo Error-status passa a ser Non-Repeaters e Error-Index passa a ser Max-
Repetitions.
A mensagem de InformRequest é dedicada a comunicação gerente-gerente, sendo
utilizada para a transmissão de informações que sejam locais a um gerente.
Para a PDU de Report não existe uma definição conhecida. Sabe-se que as citações
em relação a essa PDU são acompanhadas do seguinte comentário:
 28
“O uso da semântica que precisa da PDU de Report não são definidas. Qualquer
ferramenta de administração baseada em SNMP que faça uso desta PDU deve definir seu
uso e sua semântica”.
Depois de alguns anos de experiência com o SNMPv2 se fez revisão de suas
especificações, fazendo-se a retirada dos aspectos de segurança do SNMPv2, deixando
apenas algumas modificações. Essa nova revisão do SNMP utilizou-se do conceito de
comunidade, empregado no SNMPv1, sendo, portanto, renomeado para “SNMPv2 baseado
em comunidade” ou SNMPv2c.

Tabela 2 - RFCs relacionadas ao SNMPv2c

RFC Data Título

1901 Janeiro, 1996 Introduction to Community-Based SNMPv2
1902 Janeiro, 1996 Structure of Management Information for SNMPv2
1903 Janeiro, 1996 Textual Conventions for SNMPv2
1904 Janeiro, 1996 Conformance Statements for SNMPv2
1905 Janeiro, 1996 Protocol Operations for SNMPv2
1906 Janeiro, 1996 Transport Mappings for SNMPv2
1907 Janeiro, 1996 Management Information Base for SNMPv2
1908 Janeiro, 1996 Coexistence Between Version 1 and 2 of the
Internet-Standard Network Management Framework

Esta eliminação dos aspectos de segurança do SNMPv2 foi na verdade um

retrocesso. Os grupos de trabalho pela análise do SNMP foram surpreendidos pela falta de
consenso em relação à segurança e seu prazo havia se esgotado. Na necessidade do
lançamento dessa nova versão do SNMP optou-se por omitir as características de
segurança, reforçando e aprimorando certas características funcionais e mantendo os
prazos determinados.
De modo a corrigir os problemas de falta de segurança no SNMPv2c, dois grupos
de trabalhos foram organizados, dando origem as especificações SNMPv2u e SNMPv2*.
Em março de 1997 foi criado um grupo de trabalho pelo IETF para unificar essas duas
propostas em uma única nova versão do SNMP, o SNMPv3. Em janeiro de 1998 este
grupo de trabalho deu origem a uma série de RFCs especificando a nova versão do
 29
protocolo. O SNMPv3 incorpora características de segurança às funcionalidades já
existentes do SNMPv1 e SNMPv2.

Tabela 3 – RFCs relacionadas ao SNMPv3

RFC Data Título

RFC 2271 Janeiro, 1998 Architecture for Describing SNMP
Managements Frameworks
RFC 2272 Janeiro, 1998 Message Processing and Dispatching for
SNMP
RFC 2273 Janeiro, 1998 SNMPv3 Applications
RFC 2274 Janeiro, 1998 User-Based Security Model for SNMPv3
RFC 2275 Janeiro, 1998 View-Based Acess Control Model (VACM)
for SNMP
Internet Draft Agosto, 1998 Introduction to Version 3 of the Internet
Network Management Framework

O SNMPv3 não substitui o SNMPv1 e o SNMPv2, ele apenas apresenta

funcionalidades de segurança às duas versões anteriores do protocolo, dando preferência ao
uso do SNMPv2. O SNMPv3 apenas encapsula as PDUs (Protocol Data Units) do
SNMPv1 ou SNMPv2 na sua área de dados e acrescenta um cabeçalho. A Figura 2.2.1
mostra como se dá o encapsulamento.
 30

Figura 2.2.1 - Arquitetura do protocolo SNMPv3

Dessa forma, o SNMPv3 consegue contornar o problema que existia nas versões
anteriores, acrescentando-se as características de privacidade, autenticação e controle de
acesso sem que se necessite especificar um protocolo completamente novo, facilitando a
transição dos equipamentos que atualmente já suportam as versões anteriores. Além disso,
o SNMPv3 definiu uma arquitetura mais modular, especificando quais partes devem ser
implementadas pelos clientes e quais são as responsabilidades dos gerentes, tornando,
dessa forma, mais fácil o avanço das funcionalidades do protocolo sem a necessidade da
definição de um novo padrão, bem como propor estratégias de transição mais claras e
fáceis.

2.3 ARQUITETURAS DE GERENCIAMENTO

O modelo de gerência utilizado nas redes TCP/IP inclui os seguintes elementos
chaves:
9 Estação de gerenciamento;
9 A base de informações de gerenciamento, MIB (Management Information
Base);
9 O protocolo de gerência.
A estação de gerenciamento é normalmente um único equipamento, ou também
pode estar implementado em um ambiente distribuído ou hierárquico. De qualquer forma, a
estação de gerenciamento serve como a interface entre o sistema de gerenciamento da rede
 31
(automatizado) e o gerenciamento humano. Entre o mínimo de funcionalidade que deve ser
fornecido pela estação de gerenciamento pode-se citar:
9 Um conjunto de aplicações para análise de dados, recuperação de falhas,
entre outras;
9 Uma interface (gráfica) pela qual o gerente da rede pode monitorar e
controlar o estado da rede;
9 Capacidade de traduzir as necessidades do gerente de rede na forma dos
atuais meios de monitoração e controle dos elementos remotos da rede;
9 Manter e fornecer acesso a um banco de dados de informações extraídas
das MIBs de todas as entidades gerenciáveis na rede.
As definições do SNMP abordam somente os dois itens finais desta lista, deixando
o conjunto de aplicações e a interface a cargo de cada fabricante de sistemas de
gerenciamentos de rede.
Outro elemento fundamental é o agente de gerenciamento. Os equipamentos chave,
como hosts, pontes, roteadores, pontes, hubs e outros equipamentos podem ter
implementado um agente SNMP que é gerenciado pela estação de gerenciamento. O
agente responde por pedidos de informações e ações por parte da estação gerente (ou das
estações gerentes) e pode, assincronamente fornecer à estação de gerência, informações
que não foram solicitadas, mas que são vitais.
Os recursos na rede podem ser gerenciados através de sua representação como
objetos. Cada objeto é essencialmente uma variável que representa algum aspecto
importante do objeto gerenciado, e o dado contido nesta variável é obtido, ou preenchido,
pelo agente. A coleção desses objetos é chamada de Management Information Base (MIB).
A MIB funciona como pontos de acesso no agente para as estações de gerência. Estes
objetos são padronizados para cada classe particular de equipamentos, por exemplo,
existem MIBs para rotedores, MIBs para pontes, etc. A estação de gerência executa o
monitoramento da rede através da busca dos valores dos objetos da MIB. Da mesma forma,
a estação de gerência pode causar a execução de um agente, ou pode modificar as
configurações de um agente através da atribuição de algum valor em um objeto da MIB.
A estação de gerenciamento é ligada ao agente de um protocolo de comunicação,
um protocolo de gerência de rede. O protocolo que é utilizado no gerenciamento de redes
TCP/IP é o SNMP (Simple Network Management Protocol).
 32
O SNMP foi projetado de modo a ser simples, e o faz em três formas. Primeiro,
reduzindo o custo de desenvolvimento do software agente, diminuindo o trabalho dos
fabricantes e aumento dessa forma a aceitação do SNMP. Em segundo lugar, ele é
extensível, ou seja, os fabricantes podem estender as características funcionais do SNMP.
E finalmente, ele separa a arquitetura de gerenciamento da arquitetura dos equipamentos
do hardware, permitindo a coexistência de vários equipamentos de diferentes fabricantes.
Na Figura 2.3.1, há uma possível configuração que pode ser implementada usando o
protocolo SNMP.
O SNMP, que é parte do conjunto de protocolos do TCP/IP, está localizado no nível
de aplicação dessa suíte. Ele opera sobre o UDP (User Datagram Protocol).

Figura 2.3.1 - Possível configuração de sistema com SNMP

Para uma estação de gerenciamento de protocolos TCP/IP, está localizado no nível
de aplicação possível de um ambiente que pode suportar SNMP.
Para uma estação de gerenciamento centralizada, um processo gerente deve
controlar o acesso a uma MIB centralizada (pode estar na mesma estação) e fornecer uma
interface de gerenciamento para o usuário, que nesse caso é o gerente da rede. O processo
de gerência obtém informações da rede através do SNMP, o qual está implementado sobre
UDP e IP, sendo que o último pode estar implementado sobre qualquer outro protocolo
dependente da rede, por exemplo, Ethernet, FDDI (Fiber Data Interface) e X.25. Cada
 33
agente deve implementar o SNMP, UDP e também IP. O processo gerente é responsável
por interpretar as mensagens SNMP e controlar os valores da MIB do agente.
Nesse contexto, o gerente pode solicitar informações do agente utilizando
mensagens de get, que são respondidas pelo agente na máquina remota. Por outro lado, o
agente pode enviar informações que não tinham sido solicitadas quando da ocorrência de
algum evento através de mensagens de trap.

2.4 O MODELO DE GERENCIAMENTO DA INTERNET

Como o TCP/IP, o SNMP é um protocolo Internet. Ele é uma parte da arquitetura
de gerenciamento da Internet, que é baseada na interação de diversas entidades, como se
segue:
9 Elementos de rede - também chamados dispositivos gerenciados, os
elementos de rede são dispositivos de hardware como os computadores, roteadores, e
servidores de terminais que estão conectados a rede;
9 Agentes - são módulos de software que residem nos elementos de rede.
Eles coletam e armazenam informações de gerenciamento como o número de pacotes de
erros recebidos pelo elemento de rede. São eles que respondem as solicitações dos
gerentes;
9 Objeto gerenciado - um objeto gerenciado é qualquer elemento que possa
ser gerenciado. Por exemplo, uma lista dos circuitos TCP atualmente ativos em um host
particular é um objeto gerenciado.
Existem duas formas de gerenciamento baseada na Web. A primeira constitui-se em
gerentes SNMP usando WebServers e tem como características:
9 O browser acessa um gerente que, por sua vez, acessa as informações via
SNMP;
9 As informações são disponibilizadas em páginas HTML pelo gerente
SNMP.
A segunda forma utiliza agentes SNMP com HTTP, tendo como pontos básicos:
9 O browser acessar diretamente os recursos;
 34
9 O WebServer acessar os dados através de SNMP;
9 Os dados são disponibilizados através de páginas HTML geradas pelo
agente SNMP;
9 O recurso gerenciado deve possuir capacidade de processamento para
suportar ao mesmo tempo um WebServer e um agente SNMP.
A MIB neste contexto é uma coleção de objetos gerenciados residentes em um
armazenamento virtual de informações. Coleções de objetos gerenciados relacionados são
definidas em módulos específicos da MIB.
É usada uma notação sintática, ou seja, uma linguagem usada para descrever os
objetos gerenciados da MIB em um formato independente da plataforma. Um uso
consistente da notação sintática permite que diferentes tipos de computadores
compartilhem informações. Sistemas de gerenciamento Internet usam um subconjunto da
Open System Interconnection (OSI), o Abstract Syntax Notation 1 (ASN.1) da
International Organization for Standardization's (ISO) para definir tanto os pacotes que
são trocados pelo protocolo de gerenciamento quanto os objetos que ele deve gerenciar.
As definições das regras para descrever as informações de gerenciamento são
realizadas pela Structure of Management Information (SMI). A SMI é definida usando o
ASN.1.
Os Network Management Stations (NMS), também chamados consoles, são
dispositivos que executam aplicações de gerenciamento para monitorar e controlar
elementos de rede.
Fisicamente, os NMS são usualmente workstations com CPU velozes, monitores
coloridos de alta definição, memória substancial e um grande espaço em disco.
O SNMP é o protocolo de gerenciamento usado para transportar informações de
gerenciamento entre agentes e NMS.
Com base nesta arquitetura, o SNMP foi construído para minimizar a quantidade e
a complexidade das funções necessárias para gerenciar um agente. O paradigma funcional
de controle e monitoração do protocolo foi definido de maneira extensiva, para poder
absorver mais facilmente novos aspectos das operações de rede e gerenciamento. Além
disto, esta arquitetura é totalmente independente da plataforma dos elementos da rede e dos
NMS.
 35
Os processos que implementam as funções de gerenciamento Internet atuam ou
como agentes ou como gerentes. Os agentes coletam junto aos dispositivos gerenciados, as
informações relevantes ao gerenciamento da rede. O gerente, por sua vez, processa essas
informações com o objetivo de detectar falhas no funcionamento dos elementos da rede,
para que "possam ser tomadas providências no sentido de contornar os problemas que
ocorrem como conseqüência das falhas".
Um objeto gerenciado representa um recurso e pode ser visto como uma coleção de
variáveis cujo valor pode ser lido ou alterado. Para tanto o gerente envia comandos aos
agentes. Para monitorar os dispositivos gerenciados, o gerente solicita ao agente uma
leitura no valor das variáveis mantidas por estes dispositivos, através do comando Get, e o
agente responde através do comando Response.
Para controlar os dispositivos gerenciados, o gerente modifica o valor das variáveis
armazenadas nos dispositivos gerenciados, através do comando Put. Isto pode ser usado
para disparar indiretamente a execução de operações nos recursos associados aos objetos
gerenciados. Por exemplo, um reboot do elemento de rede pode ser facilmente
implementado, basta que o gerente modifique o parâmetro que indica o tempo até uma
reinicialização do sistema.
O gerente pode, ainda, determinar que variável um dispositivo gerenciado suporta e
colher informações de forma seqüencial, das tabelas de variáveis (como as tabelas de
roteamento IP) nos dispositivos gerenciados. Para isto, ele utiliza as operações transversais
(transversal operations).
Em alguns casos é necessário que a troca de informações seja em sentido inverso,
isto é, o agente tem de passar informações para o gerente.

2.5 DEFINIÇÃO DOS RELACIONAMENTOS ADMINISTRATIVOS

A arquitetura SNMP admite uma variedade de relacionamentos administrativos
entre entidades que participam do protocolo. As entidades residentes nas estações
gerenciadas e os elementos de rede que se comunicam com um outro elemento usando
SNMP são chamados de entidades de aplicação SNMP. O processo que implementa o
SNMP, e, portanto suporta as entidades de aplicação SNMP, é chamado protocolo de
entidades.
 36
A junção de um agente SNMP com algum conjunto arbitrário de entidades de
aplicação SNMP é chamada de comunidade SNMP. Cada comunidade é nomeada através
de uma cadeia de octetos.
Uma mensagem SNMP, originada por uma entidade de aplicação SNMP que de
fato pertence à comunidade SNMP referenciada pela mensagem, é chamada mensagem
SNMP autêntica. O conjunto de regras existentes para que uma mensagem seja identificada
como uma mensagem SNMP autêntica para uma comunidade SNMP qualquer é chamado
de esquema de autenticação.
A implementação de uma função que identifica mensagens autênticas de acordo
com um ou mais esquemas de autenticação é chamado serviço de autenticação.
Um efetivo gerenciamento das relações administrativas entre entidades de aplicação
SNMP requer que os serviços de autenticação identifiquem mensagens autênticas com
confiabilidade.
Para qualquer elemento da rede, um subconjunto de objetos na MIB que pertence a
este objeto é chamado de visão da MIB SNMP. Um elemento do conjunto (READ-ONLY,
READ-WRITE) é chamado de modo de acesso SNMP.
A junção do modo de acesso SNMP com a visão da MIB é chamada de perfil da
comunidade SNMP. O perfil da comunidade SNMP representa um privilégio de acesso
específico para variáveis em uma MIB específica. A união da comunidade SNMP com o
perfil da comunidade é chamada de política de acesso SNMP. Uma política de acesso
representa um perfil de comunidade específico proporcionado por um agente SNMP de
uma comunidade para outros membros desta comunidade. Todos os relacionamentos
administrativos entre entidades de aplicação SNMP são definidos em termos das políticas
de acesso.
Para toda política de acesso SNMP, se o elemento de rede em que o agente SNMP
especificado pela comunidade SNMP reside não contém a visão MIB que o perfil
especifica, então esta política é chamada política de acesso proxy SNMP. O agente
associado com a política de acesso proxy é chamado de agente proxy.
A política proxy é usualmente definida com a monitoração e o controle dos
elementos de rede que não são endereçáveis usando o protocolo de gerenciamento e o
protocolo de transporte. Desta forma, um agente proxy provê uma função de conversão de
protocolo permitindo a uma estação de gerenciamento aplicar um gerenciamento
 37
consistente em todos os elementos da rede, incluindo dispositivos como modems,
multiplexadores, e outros dispositivos que suportam diferentes estruturas de
gerenciamento.
Ela potencialmente protege os elementos da rede de elaboradas políticas de controle
de acesso.

2.6 OPERAÇÕES SNMP

O SNMP por si só é um protocolo de requisição/resposta simples. Os NMS podem
enviar múltiplas requisições sem receber uma única resposta. Quatro operações são
definidas no SNMP, as quais incluem as seguintes funções:
9 Get - permite que o NMS recupere uma instância de objeto do agente;
9 GetNext - permite que o NMS recupere a próxima instância de objetos de
uma tabela ou lista em um agente. Se o NMS quiser recuperar todos os elementos de uma
tabela de um agente, ele inicia uma operação Get seguida de uma série de operações
GetNext;
9 Set - permite que o NMS modifique valores de uma instância de objetos em
um agente;
9 Trap - usado pelo agente para informar assincronicamente o NMS sobre
algum evento.
Essas funções permitem uma forma de acesso muito simples aos dados que são
representados pela MIB. Desta forma, não é possível alterar a estrutura da MIB
adicionando ou apagando instâncias de objetos. Também não é possível executar
comandos para que uma certa ação seja tomada. Além disso, como o acesso é feito
somente a tipos de dados escalares, ou seja, a objetos-folha da MIB, não é possível obter
todos os objetos de uma tabela em um único comando. Estas restrições limitam as
capacidades do SNMP.
Da mesma forma que uma estação gerente pode enviar comandos get e set, além de
receber traps, de várias entidades da rede; uma estação gerenciada pode ter um conjunto de
gerentes que solicitam e atualizam informações. Assim, deve se ter um certo controle de
como é feito o acesso a MIB, através de três aspectos fundamentais:
9 Serviço de autenticação: a estação gerenciada pode limitar o acesso a
MIB para apenas certos gerentes que estejam autorizados;
 38
9 Política de acesso: ainda, podem ser dados diferentes níveis de acesso
para diferentes estações gerentes;
9 Serviço de proxy: uma estação gerenciada pode servir como proxy entre
as estações gerente e uma outra estação gerenciada, sendo de sua responsabilidade
implementar os serviços de autenticação e controle de acesso.
Esses conceitos são todos relacionados com segurança. O SNMP, como definido na
RFC 1157, implementa uma forma primitiva e limitada baseada no conceito de
comunidade. Uma comunidade no SNMP é um relacionamento entre um agente SNMP e
um conjunto de gerentes que define as características de segurança. Um agente pode
estabelecer um número de comunidades para cada aspecto de segurança desejado. Cada
nome de comunidade tem existência local ao agente, ou seja, podem existir vários agentes
utilizando o mesmo nome de comunidade sem que essas comunidades tenham qualquer
relação.
O serviço de autenticação se preocupa em assegurar que uma comunicação seja
autêntica. No caso do SNMP isto pode ser obtido através de um esquema muito simples,
onde cada mensagem SNMP é enviada para o agente contendo o nome da comunidade,
assumindo que, se o gerente conhece o nome da comunidade, então ele pode ser
considerado confiável.
Definindo uma comunidade, o agente limita o acesso a sua MIB a determinados
conjuntos de gerentes, e ainda, com vários nomes de comunidades, ele pode fornecer
diferentes categorias de acesso a MIB para cada estação gerente diferente. Assim, dois
aspectos são envolvidos: diferentes visões da MIB podem ser associadas a cada nome de
comunidade.
Os pacotes de mensagem do SNMP são divididos em duas partes. A primeira parte
contém a versão e o nome comunitário. A segunda parte contém o protocolo de unidade de
dados (PDU) do SNMP especificando a operação que será realizada ("Get", "Set" e outros)
e a instância de objetos envolvida na operação.
O campo versão é usado para garantir que em todos os elementos de uma rede estão
rodando softwares baseados na mesma versão do SNMP. O nome comunitário associa um
ambiente de acesso para um conjunto de NMS usando o nome comunitário. Um NMS
dentro de uma comunidade pode ser dito existente dentro de um mesmo domínio
administrativo. Como os dispositivos que não conhecem seu próprio nome comunitário são
 39
excluídos das operações do SNMP, então o administrador de redes usa o nome comunitário
como uma forma fraca de autenticação.
O PDU do SNMP tem os seguintes campos:
9 Tipo PDU - especifica o tipo que o PDU começará transmitindo;
9 Identificação de requisição - associa as requisições com as respostas;
9 Variáveis ligadas - incluir o dado em um PDU SNMP. Variáveis ligadas
associam instâncias particulares de objetos com seus valores correntes.

2.7 FORMATO DAS MENSAGENS SNMP

As informações são trocadas entre a estação gerenciadora e o agente na forma de

mensagens SNMP. Cada mensagem inclui o número da versão do SNMP, um nome de
comunidade e um dos cinco tipos de unidades de dado do protocolo como mostrado na
Figura 2.7.1. A Tabela 4 explica o significado de cada campo do cabeçalho de
mensagens.

Figura 2.7.1 – Formato de mensagens SNMP

 40

Tabela 4 – Formato das mensagens utilizadas no SNMP

Campo Descrição
Version Versão do SNMP, a versão definida pela RFC 1157 é 1.
Community Nome da comunidade de modo a identificar o gerente para o agente
Request-Id Usado para identificar cada mensagem de request.
Error-status Utilizado para indicar que ocorreu alguma exceção no
processamento da solicitação.
Error-index Quando o Error-status não é zero (ou seja, ocorreu algum erro)
este campo fornece informações a mais como índice da
variável que causou a exceção. Uma variável é uma instância
de um objeto gerenciado.
Variable Lista de nomes de variáveis e valores correspondentes. Em
bindings alguns casos como na mensagem de GetRequest, esses valores
são nulos.
Enterprise Tipo de objeto que gerou a trap.
Agent-addr Endereço do agente (onde está o objeto) que gerou a trap.
Generic-trap Tipo de trap genérica. Informa os tipos de valores padrões
definidos para traps, ou valor Specific.
Specific-trap Código de trap especifica, no caso do valor do campo generic-
trap ser Specific.
Time-stamp Contém o valor do objeto sysUpTime, ou seja, é o tempo desde
A última reinicialização da entidade de rede da geração da trap

As mensagens de GetRequest são utilizadas para obter instâncias de objetos que são
identificados no campo variable bindings da PDU. O agente responde este tipo de
mensagem com GetResponse, contento no campo request-id o mesmo número do pacote
de recebimento, e no campo variable bindings são colocados os valores das instâncias
 41
solicitadas. As operações de GetRequest são atômicas, ou todos os objetos solicitados são
recuperados ou é retornado um erro com o código devido.
As mensagens de GetNextRequest são praticamente iguais as de GetRequest. A
diferença é que para o GetRequest são retornados os valores das instâncias solicitadas, já
no GetNextRequest são retornados os valores das próximas instâncias àquelas solicitadas,
seguindo a ordem lexicográfica dos OIDs (Object Identifier). E ainda, da mesma forma que
o GetRequest, a operação GetNextRequest é atômica, informando um erro se algum dos
objetos solicitados não puder ser recuperado.
Ainda seguindo o mesmo padrão das mensagens GetRequest, as mensagens
SetRequest contêm os nomes das instâncias dos objetos que terão os valores de suas
instâncias alterados e os novos valores para cada uma das instâncias. O agente também
responde essa mensagem com um GetResponse contendo o mesmo request-id do pacote
recebido, e a operação de set também é atômica, se alguma das instâncias não puder ser
atualizada, seja por erro na sua identificação, seja pelo envio de um valor incorreto, será
informado um erro e a operação não será concluída com sucesso.
Ao contrário das outras mensagens, as mensagens de Trap não necessitam de
nenhuma resposta por parte da estação gerenciadora, e são enviadas assim que algum
evento de relevância tenha ocorrido na estação gerenciada. As informações enviadas por
uma Trap são muitas vezes específicas da implementação, sendo que os valores enviados
no campo variable bindings são estritamente dependentes da implementação.

2.8 PROXIES
O uso do SNMP exige que todos os agentes, bem como as estações de trabalho
suportem uma pilha de protocolos em comum, ou seja, o UDP e IP. Isto limita o
gerenciamento direto de certos equipamentos e exclui outros, como pontes e modems, que
não suportem qualquer parte da suíte de protocolos do TCP/IP. Ainda, existem numerosos
sistemas, como certos computadores pessoais que implementam o TCP/IP para suas
aplicações, mas que não desejam acrescentar o peso do SNMP, lógica do agente e dados da
MIB em seu sistema.
De modo a permitir a gerência de sistemas que não suportam a implementação do
SNMP, foi desenvolvido o conceito de proxy. Neste esquema, o agente SNMP funciona
como um proxy para um ou mais equipamentos. Veja a Figura 2.8.1.
 42

Figura 2.8.1 – Gerenciamento utilizando o conceito de proxy

Neste caso, a estação de gerenciamento manda requisições para o equipamento
onde está o agente proxy. O proxy converte a requisição para o protocolo de
gerenciamento que é utilizado pelo equipamento, podendo utilizar comunicação através do
canal serial, paralelo ou mesmo utilizando Ethernet. Assim que a resposta é recebida pelo
agente (proxy), ele converte a resposta em uma resposta padrão do SNMP e repassa para a
estação gerente. Da mesma forma, ao ocorrer algum evento no equipamento, a mensagem é
recebida pelo agente e reenviada no formato das mensagens de trap do SNMP para o
gerente. Ainda, caso o equipamento não tenha a capacidade de informar o proxy na
ocorrência de algum evento, o proxy pode ter, adicionado a sua lógica, algum
processamento de pooling, de modo a ficar a par de qualquer modificação no estado do
equipamento gerenciado.
2.9 AS VANTAGENS DO SNMP
A vantagem maior é sua popularidade. Agentes SNMP, pois como já foi dito, estão
disponíveis para dispositivos de rede que variam de computadores, pontes, modems, até
impressoras. O fato que o SNMP existe com tal apoio dá crença considerável à razão para
sua existência. O SNMP se tornou interoperável.
O protocolo só pode ser utilizado em uma variedade de dispositivos porque é
simples e concentra a maior parte do processamento na máquina do gerenciador,
permitindo que os nós da rede utilizem o protocolo mesmo não tendo grande poder de
 43
processamento.
O projeto de sistemas que envolvam estudos em SNMP é mais simples se
comparado com outros protocolos de gerenciamento de redes. Conseqüentemente é de
mais fácil implementação em redes grandes, já que não necessita de muito tempo para
configuração e não exige muito processamento dos nós da rede. Também, seu projeto
simples torna factível (embora não imediato) para um usuário programar variáveis que ele
gostaria de monitorar, pois cada variável contém apenas as seguintes informações:
9 O nome da variável;
9 Os tipos de dados da variável (inteiro, string, etc.);
9 Se a variável é somente de leitura ou de leitura e escrita;
9 O valor da variável;
O resultado líquido desta simplicidade é um gerente de rede que é fácil de
implementar e que também não impõe muito overhead em uma rede existente.
Expansibilidade é outro benefício do SNMP. Por causa de seu projeto simples, ele
pode ser atualizado de forma a adequar-se às necessidades dos usuários futuros. E como os
agentes SNMP podem ser estendidos para cobrir dados de dispositivos específicos.
Outro ponto importante, é que com a implementação do protocolo SNMP,
componentes de redes, locais ou não, podem ser monitorados e gerenciados, em princípio,
igualmente.
2.10 AS DESVANTAGENS DO SNMP
O SNMP não é de maneira nenhuma um protocolo de gerência de rede perfeito, e
assim possui falhas. Contudo, por causa de seu projeto flexível, a maioria destas
deficiências pode ser contornada.
A primeira deficiência do protocolo SNMP é que ele tem grandes falhas de
segurança, que podem dar acesso a invasores, que capturam informações na rede, ao
transitar por ela.
Estes invasores também podem desligar alguns terminais. A solução para este
problema surgiu com a expansibilidade do SNMP, verificada na versão SNMPv2, que
somou alguns mecanismos de segurança que ajudaram a combater os três principais
problemas de segurança: privacidade de dados (prevenir os invasores de ganhar acesso à
informação levada pela rede), autenticação (impedir os invasores de enviar falsos dados
pela rede), e controle de acesso (que restringe o acesso de variáveis particulares a certos
 44
usuários, removendo assim a possibilidade de um usuário derrubar a rede acidentalmente).
Na verdade, o SNMP provê pouco suporte para esquemas de autenticação. Ele
suporta apenas um esquema com duas passwords. Uma password pública permite ao
gerenciador pedir o valor de variáveis (get), e outra password privada permite ao
gerenciador fixar valores de variáveis (set). Essas passwords são chamadas communities, e
todo dispositivo conectado numa rede gerenciada por SNMP devem ter essas duas
communities configuradas. Sempre é verificada a presença de uma das communities em
cada mensagem do gerenciador para o agente, mas é descrita sem nenhuma proteção, como
texto simples, propiciando falhas de segurança. Não é difícil um invasor descobrir as
passwords e influenciar no funcionamento da rede.
Outros problemas podem ser citados: o protocolo não é muito eficiente, pois há a
transmissão de muitos dados desnecessários; a organização das variáveis na árvore MIB
também não é muito eficiente. Além disso, por usar endereçamento IP, se há um problema
de roteamento na rede e se um dispositivo não poder ser alcançado, é impossível monitorá-
lo ou reconfigurá-lo.
2.11 MÉTODOS DE IMPLEMENTAÇÃO
Como implementar o protocolo SNMP é uma questão encontrada por muitos
administradores de rede atualmente. O primeiro passo é implementar a comunicação por
TCP/IP, geralmente dando a cada nó da rede um endereço IP diferente. O passo seguinte é
adquirir (ou programar) softwares para o agente e o gerente, onde ambos geralmente já
devem vir com interface gráfica para facilitar a configuração e a visualização dos dados.
Os agentes devem ser instalados em cada nó da rede, enquanto o gerente deve ser
instalado em máquinas das quais se deseja monitorar a rede. Daí geralmente é só seguir as
instruções dos programas para configurar a rede SNMP, especificando as MIBs.
2.12 CONSTRUÇÃO DE AGENTES SNMP
Os Agentes SNMP são daemons UDP que esperam requisições na porta 161 e
enviam traps na porta 160;
Esse agente interage com o sistema de gerenciamento via SNMP, mas nenhuma
especificação existe na interação com o recurso gerenciado;
Qualquer protocolo ou método pode ser empregado: sockets, RPC, memória
compartilhada ou arquivos.
Para a construção do agente, deve-se escolher qual será o tipo de agente: extensível
 45
ou estendido. Se ele for extensível, normalmente já implementa a MIB-II e usam o SNMP
diretamente. Possuem APIs (Aplication Programming Interface) de programação para
outros agentes.
Se ele for estendido, poderá implementar normalmente complementos da MIB II
(objetos específicos) e usar o SNMP indiretamente de outro agente. Interagem com um
agente através de APIs de programação.

Figura 2.12.1 – Uso dos agentes extensivos/estendidos

O agente extensível deve implementar o SNMP, para que os agentes estendidos

utilizem;
Um problema já é resolvido diretamente em um agente estendido: o protocolo
SNMP;
A interação com os recursos ainda deve ser feita de forma proprietária;
Um agente extensível pode possuir vários agentes estendidos, interagindo com
recursos diferentes.
Normalmente um agente extensível é fornecido pelo sistema operacional
(Windows) ou por bibliotecas específicas (Unix). Além do agente, têm-se também
bibliotecas auxiliares para manipulação de estruturas do protocolo (SNMPAPI).
Existem basicamente três técnicas especiais de construção de agentes: construção
direta via sockets, proxy SNMP para extensão direta do agente e construção de agentes
estendidos via API dos agentes extensíveis.

2.12.1 TÉCNICAS DE CONSTRUÇÃO USANDO SOCKETS

Neste tipo de técnica, aloca-se a porta UDP 161 e as mensagens são recebidas
remotamente.
 46
A aplicação deve ser capaz de entender as mensagens que chegar, isto é, deve
implementar o protocolo SNMP. Depois das requisições, as respostas devem ser geradas
também de acordo com o protocolo. A aplicação deve saber enviar traps diretamente a
porta 160 remota do gerente associado. Normalmente, deve-se implementar a MIB II, além
dos objetos de gerenciamento extras.

Figura 2.12.2 – Uso dos sockets

2.12.2 TÉNICAS DE CONSTRUÇÃO USANDO PROXY

Sobrepõe-se o agente local através de um novo agente, que irá implementar objetos
extras, e chamará o agente original para os objetos anteriores. Isto evita a implementação
da MIB II.
Essa implementação possui dois problemas: duas portas são usadas para se acessar
alguns recursos. Cascateamento de proxies e duplo mapeamento em plataformas de uma
mesma máquina.
2.12.3 TÉCNICAS DE CONSTRUÇÃO USANDO AGENTE ESTENDIDO
Apenas uma porta usa SNMP no sistema: 161 do agente extensível. Os agentes
estendidos são chamados apenas quando necessário. Vários agentes estendidos associados
a um mesmo agente extensível.

Figura 2.12.3 – Uso do agente estendido

 47

CAPÍTULO 3

RMON (REMOTE MONITORING)

No capítulo 3, trata-se do protocolo RMON e cita-se as suas potencialidades.

Também se mostra como é vantajoso trabalhar com múltiplos gerentes. São
citados os tipos básicos do protocolo RMON: RMON1 e RMON2 e a forma
como eles operam. Faz-se a menção de equipamentos que implementam
serviços com esse protocolo de gerenciamento.
 48
O protocolo SNMP não é adequado para ambientes de redes corporativas
constituídas de diversas redes locais conectadas através de longa distância. Esses enlaces
de rede de longa distância, por operarem a taxas de transmissão inferiores às LANs que as
interconectam, passam a ter grande parte da sua banda de transmissão ocupada para
informações de gerenciamento. Uma solução encontrada para dirimir este problema foi o
Remote MONitoring (RMON).
O protocolo RMON oferece suporte à implementação de um sistema de
gerenciamento distribuído. Nele, fica atribuída aos diferentes elementos, tais como
estações de trabalho, hubs, switches ou roteadores, das redes locais remotas a função de
monitor remoto. Cada elemento RMON tem, então, como tarefas, coletar, analisar, tratar e
filtrar informações de gerenciamento da rede e apenas notificar à estação gerente os
eventos significativos e situações de erro. No caso de existirem múltiplos gerentes, cada
elemento RMON deve determinar quais informações de gerenciamento devem ser
encaminhados para cada gerente.
Sendo assim, os objetivos do protocolo RMON são:
9 Reduzir a quantidade de informações trocadas entre a rede local gerenciada
e a estação gerente conectada a uma rede local remota;
9 Possibilitar o gerenciamento contínuo de segmentos de redes locais, mesmo
quando a comunicação entre o elemento RMON e a estação gerente estiver
temporariamente interrompida;
9 Permitir o gerenciamento pró-ativo da rede, diagnosticando e registrando
eventos que possibilitem detectar o mau funcionamento e prever falhas que interrompam
sua operação;
9 Detectar, registrar e informar à estação gerente: condições de erro e eventos
significativos da rede;
9 Enviar informações de gerenciamento para múltiplas estações gerentes,
permitindo, no caso de situações críticas de operação da rede gerenciada, que a causa da
falha ou mal funcionamento da rede possa ser diagnosticada a partir de mais de uma
estação gerente.
 49
3.1 – OBJETIVOS DO PROTOCOLO RMON
Os dispositivos de monitoramento remoto de rede (dispositivos RMON) são
instrumentos que existem com o propósito de gerenciar uma rede. Muitas vezes estes
dispositivos são dedicados e devotam significativos recursos internos para o propósito de
gerenciamento de rede.
Uma organização pode dispor de diversos destes dispositivos, um por segmento de
rede, para gerenciar sua rede Internet.
A especificação RMON é uma definição de uma MIB. O objetivo, contudo, é
definir padrões de monitoração e interfaces para a comunicação entre agentes/gerentes
SNMP.
Os objetivos da implementação de um dispositivo RMON, são os que se seguem:
9 Operação Off-Line - esta é a condição em que a estação gerenciadora não
está em contato constante com o dispositivo RMON. Presta-se para desenhar redes de
baixo custo de comunicação (redes por acesso discado ou conexões com Wide Area
Networks - WAN) ou para acidentes onde as falhas na rede afetam a comunicação entre a
estação gerenciadora e os dispositivos RMON. Desta forma, o monitor é configurado para
coletar estatísticas e fazer diagnósticos continuamente, mesmo se a conexão com o gerente
não for possível ou apresentar falhas. O monitor pode também notificar a estação de
gerenciamento se eventos excepcionais ocorrerem;
9 Monitoramento Preemptivo - se o monitor tiver recursos disponíveis, estes
podem ser usados para executar diagnósticos continuamente e para analisar a performance
da rede. Quando uma falha ocorrer, o monitor pode notificar a estação de gerenciamento e
armazenar o histórico estatístico referente à falha. Posteriormente este histórico pode ser
enviado a estação de gerenciamento com o objetivo de se fazer um estudo mais profundo e
permitir a detecção e reparo da falha;
9 Detecção de Problemas e Geração de Relatórios - o monitor pode ser
configurado para reconhecer certas situações, mais notadamente condições de erro e checar
continuamente por elas. Quando uma destas situações ocorrer, o monitor pode registrá-la e
reportá-la a estação de gerenciamento;
9 Análise de Dados - por serem dispositivos dedicados exclusivamente ao
gerenciamento de rede e por estarem localizados diretamente no segmento monitorado da
rede, os dispositivos RMON podem fazer uma análise significativa dos dados que coletam.
 50
Por exemplo, estes dispositivos podem determinar qual host gera maior tráfego ou mais
erros na rede;
9 Múltiplos Gerentes - uma configuração de rede pode ter mais de uma
estação gerente para dar mais confiabilidade, executar funções diferentes e prover
capacidades de gerência para unidades diferentes dentro da organização.

3.1.1 CONTROLE DE MONITORES REMOTOS

Um monitor remoto (dispositivo RMON) pode ser configurado como uma função
disponível em um sistema ou como um dispositivo dedicado. Configurado como
dispositivo dedicado, o monitor é capaz de efetuar operações mais complexas.
A definição da MIB RMON contém características que suportam controle extensivo
da estação de gerenciamento. Estas características dividem-se em duas categorias:
Configuração
Tipicamente, um monitor remoto necessitará ser configurado para coletar dados. A
configuração dita o tipo e a forma de dados para serem coletados. A MIB é organizada em
grupos funcionais. Cada grupo terá uma ou mais tabelas de controle e uma ou mais tabelas
de dados. Uma tabela de controle contém parâmetros que descrevem o dado na tabela de
dados, que é somente para leitura. Assim, a estação gerente envia os parâmetros
apropriados para configurar o monitor remoto para coletar os dados desejados. Os
parâmetros são configurados pela adição de um novo registro na tabela ou alterando uma
existente. Desse modo, funções para serem executadas pelo monitor são definidas e
implementadas na tabela. Por exemplo, uma tabela controle pode conter objetos que
especifiquem a origem dos dados coletados, tipos de dados.
Para modificar qualquer parâmetro na tabela de controle é necessário primeiro
invalidar a entrada. Isto causa a retirada daquela entrada e de todos os registros associados
em tabelas de dados. A estação gerente pode então criar um novo registro de controle com
os parâmetros modificados. O mesmo mecanismo é usado para apenas desabilitar uma
coleção de dados. Quando um registro da tabela de controle é apagado, os registros das
tabelas de dados associadas são apagados, e os recursos usados pelos registros são
recuperados.
 51
Invocação de Ação
O SNMP providencia mecanismos não específicos para emitir um comando para
um agente executar uma ação. SNMP tem apenas capacidade de ler valores de objetos e
setar valores de objetos com visão MIB. Contudo, isto é possível para usar o conjunto de
operações SNMP para emitir um comando. Um objeto pode ser usado para representar um
comando, assim que uma ação específica é alcançada se o objeto é setado para um valor
específico. Um número desses objetos é incluído na MIB RMON. Em geral, estes objetos
representam estados, e uma ação é executada se a estação gerente trocar o estado (pela
troca do valor do objeto).
3.1.2 - Múltiplos Gerentes
Conforme já citado, um agente RMON pode ser submetido a múltiplos gerentes. A
qualquer tempo acessos concorrentes são permitidos para um recurso disponível em um
agente. Esta é uma característica potencial para conflitos e pode gerar resultados
inesperados. No caso de agentes RMON compartilhados, as seguintes dificuldades podem
surgir:
9 Requisições concorrentes podem exceder a capacidade do monitor para
fornecer estes recursos;
9 Uma estação gerente pode capturar e ocupar recursos de monitor por um
longo período de tempo, prevenindo seu uso por outras funções gerente desejadas por
outras estações gerentes;
9 Recursos podem ser designados para uma estação gerente onde ocorreu
uma falha e os recursos não foram liberados.
Para proceder com esses problemas, uma combinação de características de
resolução e prevenção é necessária. Ela pretende que uma simples característica na MIB
RMON suporte estes requerimentos. Associado com cada tabela de controle está um objeto
do tipo registro que identifica o proprietário de um registro particular da tabela e de
funções associadas. O rótulo proprietário pode ser usado das seguintes formas:
9 Uma estação gerente pode reconhecer recursos próprios;
9 Um operador pode identificar a estação gerente que seja proprietária de um
recurso em particular ou função e negociar para serem acessíveis para todos;
9 Um operador pode ter autoridade para liberar recursos que outro operador
tenha reservado.
 52
A especificação sugere que o rótulo proprietário contenha um ou mais desses
atributos: endereço IP, nome da estação gerente, nome do gerente de rede, localização ou
telefone.
Apesar do rótulo ser proveitoso, é importante ressaltar que o rótulo não tem ação
como uma senha ou mecanismo de controle de acesso.
Se múltiplos gerentes de rede têm acesso à tabela de controle, uma maior eficiência
pode ser alcançada pelo compartilhamento. Quando uma estação gerente quer utilizar uma
certa função no monitor, ela precisa verificar a tabela de controle relevante para ver que
função tem sido definida por outra estação gerente. Neste caso, a estação gerente pode
compartilhar a função simplesmente observando os registros de dados read-only
associados com o registro de controle. Contudo, a estação gerente que seja proprietária de
uma tabela de controle pode modificar ou apagar aquele registro a qualquer hora.
Freqüentemente, um monitor será configurado com um conjunto padrão de funções
que serão setadas quando ele for inicializado. Os registros de controle que definem estas
funções são propriedades do monitor. Por convenção, cada rótulo relevante é configurado
com uma cadeia de nome "monitor".

3.2 - RMON1 e RMON2

Dois padrões básicos de protocolo RMON são especificados: RMON1 e RMON2,
funcionalmente complementares.
O RMON1 opera somente na camada Media Access Control (MAC) e, ou seja,
"oferece recursos ao administrador da rede para monitorar o tráfego e coletar informações
estatísticas da operação de um segmento de rede local, além de realizar o diagnóstico
remoto de falhas e erros ocorridos no segmento de rede a partir de funcionalidades de um
analisador de protocolo suportadas pelo correspondente elemento RMON”.
Porém, o fato do RMON1 só trabalhar na camada MAC, significa que o este
somente apresenta estatísticas para tráfego agregado - porém não apresenta estatísticas para
camadas diferentes de várias pilhas de protocolos. Isto também significa que, por não
serem capazes de monitorar a camada de rede, os dispositivos RMON1 não distinguem o
tráfego neste segmento originado através de um roteador, o que é uma grande deficiência.
Assim, muitas aplicações usuais como uma medição do tempo de resposta cliente/servidor
 53
ou uma provisão de estatística para as sete camadas, não é possível através deste protocolo
unicamente.
O RMON2 opera, por sua vez, no nível da camada de rede e camadas superiores,
complementando, portanto o RMON1, possibilitando coletar informações estatísticas e
monitorar a comunicação fim-a-fim e o tráfego gerado por diferentes tipos de aplicação.

3.3 - Remote Monitoring Management Information Base (RMON-MIB)

A implementação das funções do protocolo RMON somente é viável mediante o
suporte de uma base de dados de gerenciamento, a RMON-MIB, associada a cada
elemento RMON da rede.
3.3.1 - Grupos da RMON1-MIB
Para a RMON1-MIB, foram especificados dez grupos básicos de variáveis, que
incluem:
9 Estatístico - mantém estatísticas de utilização, tráfego e taxas de erros
ocorridos em um segmento de rede;
9 Histórico - permite controlar o processo de amostragem (definição dos
intervalos de amostragem) de informações do grupo estatístico e registrar tais informações,
empregadas na análise do comportamento de uma rede e que oferecem subsídios para um
gerenciamento pró-ativo;
9 Alarmes - possibilitam estabelecer condições limites de operação de uma
rede que deve provocar a geração de alarmes;
9 Hosts - contêm informações relativas ao tráfego gerado e recebido pelos
hosts conectados através da referida rede;
9 Classificação de n hosts (top n hosts) - permite classificar os hosts segundo
critérios pré-definidos como, por exemplo, determinar quais os hosts conectados através da
rede que geram maior tráfego em um dado período do dia;
9 Matriz - contém informações de utilização da rede e taxa de erros na forma
de matriz, associando pares de endereços MAC de elementos de rede;
9 Filtro - define condições associadas a pacotes trafegados pela rede, que
uma vez satisfeitas implicam captura de tais pacotes pelo elemento RMON ou no registro
de estatísticas baseadas nos mesmos;
 54
9 Captura de Pacotes - determina como devem ser capturados os dados dos
pacotes trafegados pela rede, a serem enviados aos gerentes. Como default, são capturados
os cem primeiros bytes dos pacotes filtrados pelo elemento RMON;
9 Evento - define todos os eventos que implicam a criação de registros (logs)
de eventos e o envio de informações pertinentes do elemento RMON aos gerentes.
A implementação de todos os grupos é opcional, embora exista uma relação de
dependência entre alguns deles, como é o caso do grupo de "classificação de n hosts" em
relação ao grupo de hosts.
3.3.2 - Grupos da RMON2-MIB
Para a RMON2-MIB, foram especificados, também, dez grupos básicos de
variáveis, conforme, que incluem:
Diretório de Protocolo - especifica uma lista dos protocolos - de rede, transporte e
de camadas superiores - que o elemento RMON tem a capacidade de monitorar, sendo
possível incluir, remover ou configurar entradas dessa lista.
Distribuição de Protocolo - contém informações relativas ao número de bytes ou
pacotes referentes a diferentes protocolos transferidos através de um determinado
segmento de rede.
Mapeamento de Endereços - relaciona endereços MAC e endereços de rede - ou
endereços IP.
Camada de Rede do Host - contabiliza o tráfego gerado e recebido por um host,
cujo endereço de rede é conhecido pelo RMON.
Matriz da Camada de Rede - contabiliza o tráfego existente entre um par de hosts,
cujos endereços de rede são conhecidos pelo RMON.
Camada de Aplicação do Host - contabiliza o tráfego, relativo a determinado
protocolo, gerado e recebido por um host, cujo endereço de rede é conhecido pelo RMON.
Matriz da Camada de Aplicação - contabiliza o tráfego, relativo a um determinado
protocolo, existente entre um par de hosts, cujos endereços de rede são conhecidos pelo
RMON.
Histórico do Usuário - contém informações específicas de um usuário relativo ao
tráfego gerado, período e intervalos de amostragem, entre outras informações.
Configuração do Probe - contém a configuração dos parâmetros de operação do
RMON.
 55
Conformidade RMON - define os requisitos de conformidade da RMON-MIB.
3.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON
Os equipamentos a seguir possuem recursos para a utilização do protocolo RMON:
9 Switch Nways Ethernet LAN 8271 – Modelo 712;
9 Switch Nways Ethernet LAN 8271 – Modelo 612;
9 Switch Nways Ethernet 8271- Modelo 216.
 56

CAPÍTULO 4

MANAGEMENT INFORMATION BASE (MIB)

O capítulo 4, fala sobre a MIB e suas propriedades relacionadas ao

armazenamento de dados (variáveis) para estudo. A estrutura de árvores é
comentada como uma forma de organização em níveis. Explica-se como a
MIB pode ser construída e definida (bases geradas pela definição da SMI).
 57
A especificação MIB define as variáveis necessárias à monitoração e controle de
vários componentes em redes Internet. Nem todos os grupos de variáveis definidas pela
especificação MIB são obrigatórios para todos os componentes de redes Internet.
Em uma implementação SNMP/RMON os objetos gerenciados são acessados
através de um banco de dados virtual, chamado MIB. Os objetos de uma MIB são
definidos usando o padrão ASN.1. Na verdade, a MIB é uma base de dados conceitual: os
dados podem estar realmente em um SGBD (Sistema Gerenciador de Banco de Dados).
Ex: taxa de utilização de um link. Os dados podem ser encontrados nos próprios recursos.
Ex: estado atual de uma interface. Uma MIB é representada como uma árvore de dados
estruturada. Os nodos intermediários contêm subnodos, mas não contém nenhum valor
associado. Se um nodo não possui subnodos, então ele é chamado de objeto e possui um
valor associado. A identificação de cada nó é feita com o OID. O OID (Object Identifier)
de um nodo é composto pelo OID de seu pai mais o seu próprio identificador relativo. O
nodo raiz da MIB não possui o OID. A árvore é percorrida em profundidade, começando
pelos ramos da esquerda e seguido à direita. Para facilitar a compreensão, o número de
OID é substituído por um nome (OID Name).
Cada MIB define um conjunto de objetos que podem ser acessados pelo gerente. A
MIB I, publicada pela primeira vez em 1990 e definida pela RFC 1066 e 1156, apresentava
objetos para gerenciamento genérico de equipamentos. Já a MIB II, definida pela RFC
1158 e 1213, foi resultado de uma expansão e melhorias provenientes da MIB I.
Basicamente, ela permite a expansão da MIB para melhoramentos de empresas. Cada
sistema (estação de trabalho, servidor, roteador, ponte, etc) em uma rede mantém uma MIB
que reflete o estado dos recursos que podem ser gerenciados naquele sistema. Uma estação
de gerenciamento pode monitorar os recursos da rede, através da leitura dos objetos da
MIB e pode controlar esses recursos modificando esses valores. Para que a MIB tenha
utilidade, alguns objetivos se fazem necessários, são eles:
9 Os objetos usados para representar um recurso em particular devem ser os
mesmos para qualquer sistema;
9 Um esquema único para representação deve ser utilizado de modo a
permitir a interoperabilidade.
O primeiro objetivo é obtido através da definição de objetos e estruturando esses
objetos em uma MIB. O segundo objetivo é conquistado definindo uma estrutura de
 58
informações de gerenciamento (SMI). A MIB suporta somente tipos de dados simples,
escalares e matrizes bidimensionais de escalares, viabilizando a consulta das informações
de forma mais direta com o uso do SNMP, o qual também suporta apenas tipos escalares
simples de dados, incluindo entradas individuais em tabelas.

4.1 ESTRUTURA DA MIB

Todos os objetos gerenciados no SNMP são arranjados em uma estrutura
hierárquica do tipo “árvore”. Os objetos das folhas da árvore representam os atuais objetos
gerenciados, sendo que cada um deles representa um recurso, uma atividade, ou
informação relacionada que deve ser gerenciada.
Cada objeto na MIB possui um identificador do tipo ASN.1 OBJECT
IDENTIFIER, este identificador também serve como nome do objeto. Devido à forma
hierárquica de escolha desse nome, ele também serve como identificador da estrutura dos
objetos.
Como exemplo dessa estrutura utilizada na MIB, veja a Figura 4.1.1, gerada pelo
aplicativo MIB Browser, da empresa MGSoft. Este software é de simples gerência,
apresentando uma estrutura visual para a estrutura de dados da MIB. Ele é capaz de
mostrar os valores das instâncias dos objetos que são mostrados na árvore MIB.

Figura 4.1.1 – Árvore da MIB gerada pelo MIB Browser

Foi definido que o nodo Internet tem como identificador 1.3.6.1, ou seja,
iso.org.dod.internet, e serve de prefixo para os demais nodos definidos nesse mesmo
documento:
9 directory: reservado para uso futuro para OSI;
 59
9 mgmt: utilizado para objetos definidos nos documentos aprovados pelo
IAB;
9 experimental: usado para identificar objetos utilizados apenas como
experimento na Internet;
9 private: utilizados para identificar objetos definidos unilateralmente.
Objetos adicionais podem ser definidos para a MIB II de três formas diferentes:
9 A subárvore MIB II pode ser expandida, ou mesmo completamente
substituída por uma nova versão (por exemplo, MIB III). No caso de expansão, precisa-se
apenas criar um novo nodo abaixo da MIB II;
9 Uma MIB experimental pode ser construída para uma aplicação em
especial. Esses objetos inicialmente são colocados no ramo experimental, e posteriormente,
podem, passando pela aprovação dos órgãos competentes, serem colocados no ramo
mgmt;
9 Extensões privadas podem ser adicionadas na subárvore private.
A subárvore private tem, atualmente, apenas um nodo filho, enterprises, esta
porção da subárvore é utilizada para permitir que os fabricantes possam aprimorar o
gerenciamento de seus equipamentos.
Uma MIB pode ser descrita como uma árvore abstrata com um root anônimo. Os
níveis da árvore são compostos pelos ítens de dados individuais. Identificadores de objetos
(OID) identificam ou nomeiam unicamente os objetos da MIB na árvore. Identificadores
de objetos são como números de telefones, eles são organizados hierarquicamente com um
específico dígito associado por diferentes organizações.
A MIB e a MIB-II padrão para a Internet, contém 171 objetos. Estes objetos são
agrupados por protocolos (incluindo TCP, IP, UDP, SNMP, e outros) e outras categorias,
incluindo "sistemas" e "interfaces".

A árvore MIB é extensiva por força das ramificações experimentais e privadas.

Fabricantes podem definir suas próprias ramificações para definir instâncias em seus
produtos.
Abaixo da subárvore MIB II estão os objetos usados para obter informações
específicas dos dispositivos da rede. Esses objetos estão divididos em 10 grupos, que estão
presentes na Tabela 5, logo a seguir:
 60

Tabela 5 – Grupos estudados na MIB

Grupo Informação
system informações básicas do
sistema
Interfaces interfaces de rede
at tradução de endereços
ip protocolo ip
icmp protocolo icmp
tcp protocolo tcp
udp protocolo udp
egp protocolo egp
transmission meios de transmissão
snmp protocolo snmp

Alguns dos objetos pertencentes aos grupos da MIB II são:

Grupo System (1.3.6.1.2.1.1)

sysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade. Pode incluir o nome e a
versão 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 re-inicializaçãodo gerenciamento do sistema na rede.
sysContact (1.3.6.1.2.1.1.4): Texto de identificação do gerente da máquina
gerenciada e como contatá-lo.

Grupo Interfaces (1.3.6.1.2.1.2)

ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede (não 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): Número total de octetos recebidos pela interface.
 61
Grupo IP (1.3.6.1.2.1.4)
ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um gateway.
ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas recebidos pelas
interfaces, incluindo os recebidos com erro.
ipInHdrErrors (1.3.6.1.2.1.4.4): Número de datagramas que foram recebidos e
descartados devido a erros no cabeçalho IP.

Grupo ICMP (1.3.6.1.2.1.5)

icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens ICMP recebidas por esta
entidade. Incluindo aquelas com erros.
icmpOutMsgs (1.3.6.1.2.1.5.14): Número total de mensagens ICMP enviadas por
esta entidade. Incluindo aquelas com erros.

Grupo TCP (1.3.6.1.2.1.6)

tcpMaxConn(1.3.6.2.1.6.4): Número máximo de conexões TCP que esta entidade
pode suportar.
tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP que estão como
estabelecidas ou a espera de fechamento.

tcpRetransSegs (1.3.6.2.1.6.12): Número total de segmentos retransmitidos.

Grupo UDP (1.3.6.1.2.1.7)

udpInDatagrams (1.3.6.1.2.1.7.1): Número total de datagramas UDP entregues aos

usuários UDP.

udpNoPorts (1.3.6.1.2.1.7.2): Número total de datagramas UDP recebidos para os

quais não existia aplicação na referida porta.

udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do usuário UDP local.

Grupo SNMP (1.3.6.1.2.1.11)

 62

snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens recebidas pela entidade

SNMP.
snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens enviadas pela entidade
SNMP.
snmpInTotalReqVars (1.3.6.1.2.1.11.13): Número total de objetos da MIB que
foram resgatados pela entidade SNMP.

4.2 DEFINIÇÕES DE OBJETOS

A MIB é formada de objetos, sendo que cada objeto possui um tipo e um valor. O
tipo de objeto, que é uma descrição sintática, define um tipo particular de objeto
gerenciado. Uma instância de objeto especifica uma entidade particular de um tipo de
objeto que tem associado um determinado valor.
De modo a definir objetos para estender a MIB, deve-se usar a notação ASN.1, a
qual agrupa um conjunto predefinido de tipos de dados e uma gramática para definir novos
tipos que são derivados dos existentes.
A forma utilizada pelo SNMP para derivar novos tipos de objetos foi a definição
de uma macro. Esta macro cria um conjunto de tipos relacionados utilizados para definir
objetos gerenciados. A definição da macro fornece a sintaxe para um conjunto de tipos
relacionados, enquanto que uma instância da macro define um tipo específico. Desta
forma, tem-se os seguintes níveis de definição:
9 Definição da macro: define quais são as instâncias legais, especifica a
sintaxe do conjunto de tipos relacionados;
9 Instância da macro: é gerada a partir de uma definição de macro
específica através da atribuição de valores para os parâmetros da definição da macro, uma
instância de macro define um novo tipo de dado;
9 Valor de uma instância de macro: representa uma entidade específica
com um valor específico.

4.3 DEFINIÇÕES PARA SMI

A SMI (Structure of Management Information), definida na RFC 1155, especifica
como uma MIB pode ser definida e construída. Ela identifica os tipos de dados que podem
 63
ser utilizados na MIB e especifica como os recursos são reapresentados e nomeados. A
SMI procura a simplicidade e a escalabilidade.
Ela especifica que todo objeto gerenciado deve ter um nome, uma sintaxe e um
código. O nome é o identificador de objeto. A sintaxe define o tipo de dados dos objetos
(por exemplo, inteiro ou string). Um subconjunto da definição ASN.1 é usado para a
sintaxe SMI. O código descreve como a informação associada a um objeto gerenciado é
formatada como uma série de itens de dados para transmissão na rede. Outra especificação
ISO, chamada Base Encoding Rules (BER), detalha os códigos SMI.
Os tipos de dados SMI são divididos em três categorias: tipo simples, tipo de
grandes aplicações e tipo construtor simples.
Os tipos simples incluem quatro tipos ASN.1 primitivos:
9 Inteiros - valores negativos ou positivos de todos os números, inclusive o
zero;
9 Cadeia de octetos - seqüência ordenada de zero ou mais octetos;
9 Identificadores de objetos - conjunto de todos os identificadores de objetos
alocados de acordo com as regras especificadas pelo ASN.1.
Tipos de dados de grandes aplicações referem-se aos tipos de dados especiais
definidos pelo SMI:
9 Endereços de rede - representam um endereço de uma família particular de
protocolos;
9 Contadores - inteiros não negativos são incrementados de um em um até
atingirem um valor máximo, quando eles são resetados e voltam a zero. O número total de
bits recebidos em uma interface é um exemplo de contador;
9 Medidas - inteiros não negativos que são incrementados ou decrementados,
porém atrelados a um valor máximo. O tamanho da fila de saída de pacotes é um exemplo;
9 Checagem de tempo - o tempo de um evento. O tempo necessário para uma
interface chegar ao estado corrente é um exemplo;
9 Opaco - representa uma codificação arbitrária. Este tipo de dados é usado
para passar uma cadeia de informações arbitrárias que não está de acordo com a tipagem
de dados usada no SMI;
 64
9 Inteiros - representa uma informação com valores inteiros sinalizados. Este
tipo de dados redefine o tipo de dados simples "inteiro" do ASN.1, que tem uma precisão
arbitrária no ASN.1, porém uma precisão determinada no SMI;
9 Inteiros sem sinal - representa uma informação com valores inteiros não
sinalizados. Ele é útil quando os valores são sempre não negativos. Este tipo de dados
redefine o tipo de dados simples "inteiro" do ASN.1, que tem uma precisão arbitrária no
ASN.1, porém uma precisão determinada no SMI.
O tipo construtor simples inclui dois tipos ASN.1 que definem múltiplos objetos em
tabelas e listas:
9 Linha - referência a uma linha de uma tabela. Cada elemento de uma linha
pode ser um tipo simples ou um tipo de grandes aplicações;
9 Tabela - referência a uma tabela com zero ou mais linhas. Cada linha pode
ter um número qualquer de colunas;
 65

CAPÍTULO 5

ESTUDO DE CASO

Neste capítulo, foi feito um estudo de caso com a aplicação do SNMP sendo
realizada conjuntamente com Controladores Lógico-Programáveis. Este
estudo tem como base o projeto realizado pelo estudante Alexandre Cervieri,
diplomado em Ciências da Computação, pela UFRS em dezembro 1999.
Procurou-se enfocar os pontos chaves utilizados no trabalho, sem abordar
muito a parte de configurações, que foram próprias do autor original. No
texto, foi exposto algumas propostas sugeridas por Alexandre, das quais, uma
serviu como base para sua implementação.
 66
5.1 APLICAÇÃO COM CLP – CONTROLADORES LÓGICO-
PROGRAMÁVEIS
Os CLPs são os substitutos eletrônicos para grandes painéis de relés em aplicações
de chão de fábrica, e não somente para atividades de controle repetitivas que envolvem
temporização simples, lógica, e sequenciamento de entradas e saídas discretas. O avanço
tecnológico aumentou muito as suas funcionalidades, acrescentando às suas aplicações:
funções de controle de variáveis, aquisição de dados, geração de relatórios e controle
supervisório.
Os CLPs se adaptam a sistemas que precisam de uma grande confiabilidade; onde
seja necessária uma baixa ocupação de espaço físico e haja uma grande quantidade de
dados, necessitando de equipamentos que permitam uma fácil e não traumática expansão.
Com o desenvolvimento das tecnologias de redes de computadores, tornou-se uma
prática comum que nos grandes sistemas industriais houvesse uma interligação de vários
controladores programáveis utilizando essas redes. Além dos controladores, possui-se
ligados a essas redes vários módulos acessórios, como dispositivos de entrada e saída
analógicos e digitais, dispositivos de terminal para interação com o usuário, entre outros.
5.2 - ARQUITETURA DE UM CLP
Um controlador programável é um dispositivo utilizado para o controle de
máquinas ou processos utilizando um programa armazenado em sua memória e os dados
obtidos dos dispositivos de entrada e saída. Ele funciona como sendo um equipamento
digital eletrônico com uma memória programável para o armazenamento de instruções de
forma a implementar funções específicas como lógicas de sequenciamento, temporização,
contagem e aritmética para o controle de máquinas e processos.
De forma a permitir a integração entre os softwares de gerência e os
controladores, o autor do projeto, Alexandre Cervieri, criou uma MIB contendo os
principais objetos a serem gerenciados e um agente capaz de responder às requisições dos
gerentes para esses objetos.
5.3 PROPOSTA DE MIB
Para construção da MIB, Alexandre buscou inicialmente a identificação dos
elementos fundamentais que poderiam ser gerenciados remotamente.
Procurou-se elementos que fossem comuns a todos os controladores utilizados
como casos de estudo, de forma a poder criar uma MIB genérica de controle.
 67
A forma de organização da MIB foi feita dividindo-a em objetos de gerenciamento
específicos genéricos, seguindo o modelo adotado pela MIB II.
5.4 TRAPS
As traps importantes que foram definidas nessa MIB são aquelas que informam
sobre a alteração do modo de execução do controlador e do tempo de ciclo.
5.5 ALTERNATIVAS DE IMPLEMENTAÇÃO DO AGENTE
5.5.1 AGENTE NO PRÓPRIO CLP
A solução realizada por Alexandre foi a criação de um agente SNMP no próprio
controlador programável, conforme a Figura 5.5.1. O controlador já possuía suporte aos
protocolos da pilha TCP/IP, proporcionando uma economia nos gastos, os quais seriam
maiores se cada controlador tivesse que ser equipado com o agente completo, pilha de
protocolos TCP/IP e todo o hardware que porventura fosse necessário acrescentar para a
sua implementação.

O autor do projeto procurou não alterar a temporização das atividades, caso

contrário suas atividades de controle do controlador, extremamente ligadas a limites de
tempo bem determinados, estariam prejudicadas.
Existem famílias de controladores que não possuem nem mesmo interface de rede
Ethernet, e por esse motivo dependem de módulos de comunicação auxiliares. Neste caso,
uma solução seria implementação do agente SNMP nestes módulos, assim como
apresentado na Figura 5.5.2. Como normalmente eles já apresentam a pilha de protocolos
TCP/IP, a inserção do software agente não afetaria de forma muito significativa o
funcionamento do resto do sistema, mesmo sendo um módulo em separado dedicado à
troca de mensagens.
 68
Considerando que na maioria dos sistemas que adotam controladores programáveis
existe um computador próximo destes CLPs com o objetivo de dar suporte ao software
supervisório, foi adotada a solução de um agente do tipo Proxy, como apresentado na
Figura 5.5.3. Este agente poderia ser implementado, portanto, em um computador pessoal,
com um sistema operacional Microsoft Windows, LINUX, FreeBSD, ou outro existente e
implementaria o SNMP e também o protocolo proprietário existente no controlador,
servindo como um gateway entre eles.

A preocupação quanto às implicações temporais continuaram, mas em um sistema

como esse seria possível o uso de alternativas de armazenamento temporário de certas
informações no computador, tornando possível a economia de alguns acessos ao
controlador.
Tais vantagens, aliadas a relativa simplicidade de implementação de um agente em
um sistema operacional de mercado, fizeram com que esta fosse a solução adotada neste
trabalho.
5.5.2 AGENTE COMO UM PROXY
Alexandre procurou um pacote de softwares que pudesse ser instalado no mínimo
de hardware possível sem que se perdesse em desempenho.
O LINUX da distribuição Conectiva, versão 4.0, foi o sistema operacional usado.
Para a execução do agente não se teria a necessidade de uma interface de janelas, pois a
interação agente/usuário não seria feita localmente, mas apenas através do software
gerente. Dessa forma, descartaram-se os sistemas operacionais como Microsoft NT,
Microsoft Windows 95/98. Assim, foi desnecessária a instalação de qualquer interface
gráfica para o LINUX, como KDE, Gnome entre outras.
Uma das possibilidades de implementação do agente sugerida foi a criação de todos
os procedimentos referentes ao recebimento de mensagens SNMP, ou seja, escuta na porta
padrão, recebimento e interpretação dos pacotes, dos OIDs e execução dos procedimentos
cabíveis para cada tipo de mensagem, seja Get, GetNext ou Set.
O pacote básico escolhido foi o UCD-SNMP, versão 3.6.1, muito utilizado pela
 69
comunidade LINUX, pois implementa as versões 1, 2 e está em desenvolvimento a versão
3 do SNMP. Um agente estendido pode ser criado utilizando qualquer umas dessas
versões.
Com a utilização desse pacote, as tarefas de receber as mensagens da porta UDP
padrão do SNMP fica a cargo do pacote UCD-SNMP. Da mesma forma que a
interpretação dos pacotes e dos OIDs. O suporte a agentes estendidos indica que quando o
UCDSNMP está realizando a interpretação dos OIDs, assim que um deles não é
encontrado em suas MIB padrão esse OID é enviado para os módulos relativos aos
gerentes estendidos para que possam ser processados e identificados ou não como OIDs
válidos para as MIBs estendidas.
5.6 – IMPLEMENTAÇÃO DO SOFTWARE AGENTE
A Figura 5.6.1, mostra um protótipo do projeto dividido em três módulos de
programação diferentes módulo clpMIB é responsável pela implementação da extensão do
agente do UCD-SNMP.

Figura 5.6.1 – Módulos usados para interfacear com o CLP

Ele foi gerado a partir da MIB desenvolvida para os CLPs utilizando-se um script
que é parte integrante do pacote UCD-SNMP, o qual interpreta a MIB e gera as estruturas
de dados e funções básicas para a implementação da MIB. Assim, este módulo contém os
procedimentos que são chamados pelo pacote da UCD quando do recebimento de alguma
mensagem do SNMP que diga respeito a algum objeto da MIB implementada por este
módulo estendido.
 70
O módulo alnetii implementa um protocolo de comunicação, responsável por
estabelecer um canal de comunicação com o controlador programável para a busca das
informações necessárias, fazendo isto através de TCP/IP. Para isso, foi acrescido um
módulo Ethernet ao bastidor onde estava conectado o controlador programável.
O módulo snmpalnet conecta estes dois módulos citados, podendo-se fazer
qualquer alteração tanto no módulo clpMIB, quanto no alnetii e manter a mesma interface
de comunicação representada pelas funções contidas no módulo snmpalnet.
Esse módulo ainda é responsável pelo pooling periódico no controlador de forma a
buscar o valor atualizado do status do equipamento.
No momento que o gerente solicita o valor do objeto, ele envia uma mensagem de
Get ou GetNext para o agente. Neste momento, a parte do agente que recebe a solicitação é
a do pacote UCD-SNMP. Assim que ele descobre que não possui as informações
necessárias para responder àquele objeto, ele começa a verificar nos seus agentes
estendidos que foram cadastrados.
Nesse momento é solicitada a operação de leitura do objeto para o módulo
snmpalnet. Através de uma função, a solicitação é repassada para o módulo alnetii.
Ao final, é feita a conexão com o controlador, a fim de buscar o valor atualizado do
seu modo de execução.
5.7 OBSERVAÇÕES LEVANTADAS NESTE ESTUDO
Pelo estudo realizado neste estudo de caso, notou-se que esta área de gerência,
associada ao uso do CLP é muito promissora. Alguns fabricantes já estão seguindo a
tendência de adotar o padrão SNMP para o gerenciamento de seus controladores,
apresentando propostas e alguns produtos já gerenciáveis com esse protocolo.
Entre as possibilidades de extensão do trabalho desenvolvido, está a inserção de
cuidados mais específicos com segurança na forma de gerenciamento, com a adoção do
SNMPv3, por exemplo.
Pode-se acrescentar como trabalhos futuros o estudo da possibilidade de
implementação do agente não mais como um proxy, mais sim nos próprios controladores
ou em módulos TCP/IP acessórios. Isto poderia ser feito através do acréscimo de partes de
hardware ou módulos de programação complementares.
 71

CAPÍTULO 6

SOFTWARES DE GERENCIAMENTO SNMP/RMON

No capítulo 6, trata-se dos softwares de gerenciamento,

primeiramente de uma forma geral e posteriormente, depois de
enfocadas as suas propriedades, foi feito um restrição aos
aplicativos MRTG e WhatsUP. Trata-se, também, do projeto
FreeNMS, em desenvolvimento pela PUC do Rio Grande do SUL.
 72
6.1 O PAPEL DOS SOFTWARES DE GERENCIAMENTO
O crescimento exponencial do número de equipamentos interconectados através de
redes de computadores tem resultado em enormes dificuldades para os administradores de
rede, devido à complexidade no gerenciamento.
O principal objetivo dos softwares de gerenciamento é auxiliar o gerente de uma
rede no monitoramento e detecção de problemas. Existem basicamente quatro tipos de
ferramentas: ferramentas a nível físico, que detectam problemas em nível de cabos e
conexões de hardware, tais como cabos abertos e mau funcionamento em hardware de
conexão; monitores de rede, que se conectam a redes, monitorando o tráfego. Analisadores
de rede, que auxiliam no rastreamento e correção de problemas encontrados nas redes,
analisando o tráfego na rede, capturando e decodificando pacotes e sua transmissão em
tempo real; sistemas de gerenciamento de redes integrados (SGRI), os quais permitem o
monitoramento e controle de uma rede inteira a partir de um ponto central.

6.2 PLATAFORMAS DE GERENCIAMENTO

Uma plataforma de Gerenciamento pode executar várias aplicações de gerência de
desempenho, tendo estes pontos em comum. Todas devem, por exemplo, saber a topologia
de rede, todas devem ter mecanismos de conversa com agentes através do protocolo de
gerência, todas devem ter formas simples de apresentar informação gráfica ao usuário.
Uma plataforma de Gerência é um software especial que possui as seguintes
características:
9 Contém toda a funcionalidade comum a várias aplicações de gerenciam:
algoritmos de autoconhecimento de topologia, editores gráficos de topologias, uma base de
dados de tecnologia, rotinas de acesso a MIB dos agentes utilizando o protocolo de
gerência, armazenamento dos valores recebidos dos agentes numa base de dados, etc;
9 Contém uma aplicação simples de gerência que permite, pelo menos,
visualizar graficamente a evolução com o tempo dos valores das variáveis dos agentes. Há
um aplicativo muito utilizado com este tipo de aplicação chamado MIB Browser;
9 Contém uma API (Aplication Programming Interface) que permite que
várias aplicações especiais sejam construídas e inseridas na plataforma lançando mão de
todos os recursos oferecidos pela plataforma;
 73
9 Apresenta uma interface amigável com o usuário, permitindo que qualquer
usuário interaja sem necessidade de treinamento, preferencialmente baseada na WEB;
9 Livre de plataforma, podendo assim gerenciar qualquer dispositivo
independente da plataforma;
9 Monitoramento do tráfego em um agente através de gráficos. Através
destes gráficos podem ser feitos levantamentos do perfil do tráfego, verificando a
performance do equipamento e o tráfego total em um agente SNMP.
Ferramentas mais completas são oferecidas para manter e monitorar configurações
distintas de grandes redes. Por exemplo, a HP oferece o pacote Open-View e a Sun oferece
o Sun-Net Manager. Ambas são pagas. De domínio público, uma solução é o programa
Scotty.
Existem também muitos utilitários para MIB. Compiladores, como o SMIC, o
SMICNG e o SNACC; browsers como o Tk/Tcl Mib Browser; MIBs específicas como as
da Cisco, IBM, etc.
Há também linguagens de programação específicas para SNMP, como o
SNMPPerl. Agentes e gerentes podem ser programados com diversas linguagens, como C
ou até mesmo Java, usando pacotes específicos como JMGMT, JMAPI, JDMK. Mas a
maneira mais fácil de se fazer um agente é customizar um agente extensível.

6.3 – O PROJETO FREENMS

O projeto FreeNMS – Free Network Management System, está sendo desenvolvido
por um grupo de pesquisadores (de graduação e pós-graduação) do Laboratório ReMAV
(Redes Metropolitanas de Alta Velocidade) Metropoa da PUCRS, tendo como objetivo
maior o desenvolvimento de uma Plataforma de Software Livre para Gerência de Nível de
Serviço que visa auxiliar as empresas diante dos novos desafios de Qualidade de Serviço
(QoS) exigidos pelos clientes, através de contratos SLA (Service Level Management).
O sistema já se encontra em fase de testes e tem alcançado resultados plenamente
satisfatórios em duas grandes operadoras locais.
O FreeNMS trata-se de um Software Livre para Gerência de Redes, usando SNMP
(Simple Network Management Protocol) e outras tecnologias para a gerência automatizada
e integrada de grandes redes. Como diferencial, possui além das características tradicionais
de uma Plataforma de Gerência de Redes, funcionalidades de acompanhamento de
 74
Qualidade de Serviços (QoS) contratados (contratos estes denominados SLA – Service
Level Agreement).
O FreeNMS realiza coletas periódicas de diversas informações dos equipamentos
gerenciados e armazena-os na base de dados da aplicação. Através da análise destes dados
é que relatórios são gerados e alarmes de quebra de SLAs são disparados.
O modelo tradicional de um NMS (Sistema de Gerência de Redes), consiste em
uma aplicação Gerente requisitando informações dos Agentes. Em muitos casos os
Agentes também tomam a iniciativa de se comunicar com o Gerente, enviando alarmes
(denominados traps) sobre um evento anormal (queda de link, tentativas de acesso
forçadas com senhas erradas etc).
As requisições das informações de gerência são em espaços de tempo pré-
determinados, assim a cada 5 minutos tem-se uma atualização no Banco de Dados da
aplicação Gerente sobre o status atual de cada um dos equipamentos gerenciados pelo
NMS. Desta forma, é possível realizar um levantamento sobre todo o histórico, sobre o
funcionamento atual, diário, semanal, mensal e anual, através da geração de relatórios e
gráficos estatísticos.
Em ambientes com muitos equipamentos, o acúmulo de tráfego neste segmento
seria tão grande que traria sérios problemas para a própria rede gerenciada. A solução
desenvolvida para este problema no FreeNMS foi a concepção de pollers distribuídos.
No FreeNMS, foi desenvolvida uma arquitetura de Banco de Dados distribuído,
permitindo que pollers também estejam geograficamente distribuídos. Estas bases de dados
distribuídas são as que recebem todos os dados dos equipamentos da rede do domínio de
gerência respectivo. Estas bases distribuídas por sua vez são replicadas e atualizam o banco
de dados “central”, que então é o que acumula as informações totais da rede. Nesta base
central é que são obtidos dados de todos os equipamentos da rede para a geração dos
relatórios e que concentra o cadastro e o acesso de usuários ao sistema como um todo.
Lista-se abaixo, as funcionalidades básicas do sistema FreeNMS:
9 Geração de Relatórios e Gráficos diversos sobre o status da rede;
9 Detecção imediata de falha de rede em equipamentos (nodes down);
9 Realizar Descoberta de Rede (Network Discover) e detecção automática e
constante de novos (ou retirada de) nodos da rede;
9 Mapa gráfico da rede gerenciada, com status de nodos up e nodos down;
 75
9 Interface totalmente baseada na Web (Web-based);
9 Sistema Coletor (poller) multi-thread de coleta de variáveis SNMP e status;
9 Permite a existência de pollers distribuídos (gerência distribuída);
9 Independência do SGBD (Sistema Gerenciador de Banco de Dados);
9 Atualmente suporte aos bancos PostgreSQL e MySQL;
9 Sistema totalmente desenvolvido com (e para) Softwares Livres;
9 Permite a criação de Usuários e Domínios de Gerência.

6.4 – MRTG (MULTI ROUTER TRAFFIC GRAPHER)

O MRTG é um programa que gera páginas HTML, onde apresenta dados de
monitoração provenientes de variáveis de gestão nos equipamentos.
Basicamente o Multi Router Grapher – MRTG é uma ferramenta para monitorar o
tráfego na rede, a utilização de interfaces, links de redes, utilização de CPU e qualquer
outra variável numérica de equipamentos que suportem estas características de
gerenciamento.
As páginas HTML geradas utilizam imagens GIF atualizadas em um determinado
período de tempo. Estas páginas representam os dados obtidos dos dispositivos
gerenciados.
Para poder visualizar os dados deste aplicativo, é precisa ter um servidor HTTP
instalado na estação onde se pretende instalá-lo. E depois disso, instalar o pacote via apt-
get. Após ter instalado devidamente o mrtg deve-se proceder à sua configuração.
Ele pode funcionar através de uma plataforma Unix/Linux e Windows NT
Como requisitos de máquina, temos como configuração mínima: Pc 486 DX 100/66
MHz, 16 MB de memória.
Primeiramente, antes de instalar o MRTG, é necessário ter um HD de boa
capacidade, devido aos logs que o MRTG gera, e aos gráficos que são montados utilizando
arquivos no formato GIF.
A Figura 6.4.1 mostra gráfico gerado com o uso do MRTG.
 76

Figura 6.4.1 – Gráfico gerado pelo MRTG

Baseado na linguagem Perl e C, é aconselhável ser usado juntamente com um

servidor WEB (exemplo: Apache) para facilitar as consultas aos gráficos de
monitoramento. Utiliza o SNMP para ler as informações dos dispositivos gerenciados e
programas escritos em linguagem C para montar os gráficos. Estas páginas geradas pelo
MRTG podem ser consultadas de qualquer computador que possua um browser instalado.
É interessante utilizar o MRTG em conjunto com um outro software de
gerenciamento de redes, com suporte a SNMP, como o WhatsUP.
A coleta é pontual, possibilidade de visualização diária, semanal, mensal e anual
das estatísticas geradas nos gráficos. Isto é possível, pois o MRTG armazena os logs das
informações dos equipamentos contendo as datas.
O MRTG possui um programa (cfgmaker) para geração de arquivos de
configuração onde é especificado <comunidade>@<host ou IP> e o identificador das
variáveis a serem coletadas.
Para gerar um gráfico é necessário conhecer o OID da variável que o agente
responde. O MRTG não possui um limite de equipamentos para se gerenciar, e pode
monitorar qualquer variável SNMP. As variáveis mais usadas são: taxas de utilização do
canal, utilização do modem e carga de CPU.
Para que o MRTG tenha um bom funcionamento é necessário que todos os
dispositivos que serão gerenciados tenham o agente SNMP habilitado. O servidor MRTG
precisa ter permissão de leitura das informações de gerenciamento nestes agentes.
Como o MRTG é uma coleção de scripts escritos em Perl é necessário que se tenha
uma versão do interpretador de comandos Perl para a plataforma na qual se deseja instalar
o MRTG.
 77
6.5 – WHATSUP
O WhatsUp Gold da Ipswitch, é uma aplicativo que confere aos administradores de
redes a capacidade de descoberta, mapeamento, monitoramento e notificação, verificando
o status da rede em tempo real, os clientes podem monitorar todo o hardware de rede: PCs,
servidores, roteadores, repetidores, concentradores LAN, impressoras e dispositivo de
usuário final: além de serviços como SMTP, POP3, FTP, Telnet, WWW e NNTP a partir
de uma única aplicação.
O WhatsUp, permite monitorar além destas portas/serviços já pré-definidos pelo
software, uma série de outras portas/serviços que podem ser configurados pelo
administrador da rede.
Apresenta uma boa interface, com fácil instalação e utilização. Permite mapear a
rede ou montar uma rede personalizada. Os mapas são criados através do escaneamento de
redes TCP/IP, Novell NetWare IPX, e Microsoft NetBIOS.
O WhatsUp roda na plataformas: Windows 95/98/NT/2000 e necessita da seguinte
configuração mínima: PC 486/66 MHz, 15 MB de espaço em disco, 16 MB de memória
RAM (win95/98)/32 MB RAM (Windows NT/ Windows 2000).
Quando o WhatsUp é inicializado duas opções são disponibilizadas:
9 Discover and Map Network Devices;
9 Create a Blank Map.
Escolhendo a primeira opção, o WhatsUp, se encarregará de vasculhar a rede em
busca dos dispositivos presentes.
Ao criar-se um host ou escolher-se um host já definido, nos é apresentada uma tela
com uma série de utilitários. Falar-se-á agora, das principais de guias para análise:
Guia Geral:
Têm-se informações como o nome do host, o nome que vai aparecer no mapa, o
endereço IP, o tipo da máquina: se é servidor, WorkStation, Servidor, Bridge, Router,
Impressora, Windows NT Server, Windows NT Workstation. Escolhe-se o método de
Polling: ICMP, TCP/IP, NetBIOS, IPX.
 78

Figura 6.5.1 – Guia Geral

Guia SNMP
Aqui, define-se a comunidade de leitura e de escrita de um determinado host com
suporte a SNMP. O Object ID é automaticamente posto após o escaneamento da rede,
recebendo as traps enviadas pelos agentes ou gerentes. As traps ficam todas armazenadas
em um arquivo de log, que podem ser conferidas na guia Logs.

Figura 6.5.2 – Guia SNMP

 79
Para que o Object ID seja identificado, é necessário que as comunidades de leitura
e/ou escrita estejam corretas.
O WhatsUp utiliza o SNMP para montar redes separando-as de acordo com
os níveis de subrede.
Guia Monitor:
Nesta guia têm-se algumas opções de monitoramento. Nela pode-se determinar a
freqüência de Poll, o tempo de timeout, os dias e horários de monitoramento para aquele
host e a quem um determinado host estará conectado.

Figura 6.5.3 – Guia Monitor

Guia Services:

Nesta guia, o WhatsUp possibilita um escaneamento automático de um

determinado host identificando de forma automática os serviços disponibilizados pelo
mesmo.
 80

Figura 6.5.4 – Guia Services

Guia Alerts:
As notificações podem ocorrer através de alarmes sonoros, traps SNMP, e-mail,
Pager, bip ou execução de algum programa, para uma ou para um grupo de pessoas.

Figura 6.5.5 – Guia Alerts

 81

Para realizar uma notificação via trap, basta configurar a porta de escuta no
WhatsUp. O Whats Up receber estas traps, previamente configuradas nos agentes.
A notificação por e-mail é de grande utilidade, pois permite ao administrador
verificar possíveis problemas que estejam acontecendo nos dispositivos gerenciados de
uma máquina qualquer. As notificações chegam ao WhatsUp e este como forma de alerta
envia uma mensagem para o administrador com o(s) problema(s).
O WhatsUp permite ainda enviar e-mails para celular. Esta funcionalidade é
importante, permitindo que o administrador saiba imediatamente quando um determinado
problema ocorreu estando ele onde estiver.
O único problema das mensagens por e-mail é o excessivo número de mensagens
geradas. Há uma notificação quando um host/serviço ficou Down e também quando este
voltou a ficar UP.
Guia Notes:
Nesta guia é onde estão as informações gerais a respeito de um determinado host.
Estas informações devem ser colocadas de forma manual pelo administrador da rede ou
pela pessoa que for a responsável pela utilização do software.

Figura 6.5.6 – Guia Notes

 82
Guia Menu:
A ferramenta inclui os serviços: Ping, Traceroute, LookUp, Finger, Whois, LDAP,
Quote, Scan, SNMP, e Throughput; e permite configurar aplicações de FTP e Telnet. Estas
ferramentas podem ser utilizadas para analisar o comportamento de objetos gerenciáveis.

Figura 6.5.7 – Guia Menu

Depois de criado o host, ao clicar-se nele, novas funções/guias estarão incluídas.

Uma outra característica deste software é o fato de gerar relatórios de eventos,
facilitando assim o trabalho do administrador, que pode identificar os dias (dia, mês, ano,
hora) em que houveram problemas em um determinado host, ou quais os dias em que
houve mais tráfego na rede.
Este gráfico de desempenho demonstra os dados agregados a um determinado
dispositivo, exibindo a melhor e/ou pior disponibilidade, e o dispositivo com o tempo de
resposta mais alto e mais baixo e ainda os melhores e piores dias da semana para
desempenho de rede.
 83

A seguir se fornece uma relação de alguns dos softwares usados para fazer gerência
em SNMP:

Tabela 6 – Softwares de Gerenciamento SNMP/RMON

Características
Softwares Plataforma Fabricante Site do Fabricante
Servers Windows Woodstone http://www.woodstone.nu
Alive 95/98/NT/2000 e Computer
Linux Consulting
Whats Up Windows IPSwitch http://www.ipswitch.com
95/98/NT/2000
AdvanNet V5 Windows Advent http://www.adventnet.com
Monitor 95/98/NT/2000 e
Linux
AdvanNet Windows Advent http://www.adventnet.com
SNMP Utilities 95/98/NT/2000 e
Linux
Network Windows Network http://www.networkview.com
View 95/98/NT/2000 View
UCD SNMP Windows University http://ucd-snmp.ucdavis.edu
95/98/NT/2000 e of Califórnia,
Linux Davis
MRTG Unix/Linu Tobias http://ee-
x e Windows NT Oetiker e muitos staff.ethz.ch/~oetiker/webtools/mrtg/m
contribuintes rtg.html
RRDTools Unix/Linu Tobias http://ee-
x e Windows NT Oetiker e muitos staff.ethz.ch/~oetiker/webtools/eedtoll
contribuintes
MIB Master Windows Equivalenc http://www.equival.com
95/98/NT/2000 e e
Linux
 84
CONCLUSÃO
Desde o surgimento das redes de computadores seu grau de complexidade e
abrangência aumentou exponencialmente, surgindo à necessidade de utilizar sistemas de
gerenciamento eficientes para garantir sua interoperabilidade. Para isso, há entre vários
outros modelos de gerenciamento, o baseado no protocolo SNMP.
Entretanto, a gestão prática deste não está sendo amplamente utilizada pelos
profissionais da área de informática, atribui-se essa deficiência a alguns fatores como a
dificuldade de implementação uma vez que ainda não existem ferramentas amplamente
difundidas para este fim.
Nesse trabalho, foi feito um estudo criterioso sobre as funcionalidades dos
protocolos SNMP e RMON. Além disso, procurou-se mostrar alguns estudos que foram
feitos utilizando estes protocolos: projeto com CLP e FreeNMS. Mostrou-se os programas
que serviram de base para as aplicações.
Sobre o uso do SNMP com o CLP demonstrou que será de grande importância para
a indústria diminuir custos, otimizar os seus processos e assim, garantindo a melhor
qualidade de seus serviços. Já através do projeto FreeNMS, pode-se observar que
futuramente este poderá ser usado para monitorar os recursos da Internet em nível de
WAN, usando pouco mão-de-obra humana e isso garante um menor custo-benefício para
as grandes empresas que utilizam essas aplicações. Com o projeto FreeNMS funcionando
plenamente, aumentar-se-á a segurança quanto a disponibilidades do serviço. Isso será
importante para as empresas que fazem os seus negócios pela Internet: compras, vendas,
cadastros, consultas.
No início do estudo sobre esse assunto,SNMP/RMON, não se tinha idéia do seria
esses protocolos e desejava-se realizar alguma experiência prática.Porém, isso não foi
possível de se realizar por diversas razões de ordem técnica e de tempo.
Isto posto, conclui-se que os avanços na área de gerência fornecem grandes
mudanças na maneira de poder “enxergar” os elementos da rede e dar a eles a devida
manutenção: prevenindo erros ou diagnosticando-os corretamente, expandindo a
capacidade da rede (assim que se fizerem necessários) e aproveitar melhor os recursos já
existentes e que este trabalho foi muito esclarecedor para seus autores.
 85

REFERÊNCIAS BIBLIOGRÁFICAS

1- MILLER, MARK A.; Managing Internetworks with SNMP, The definitive

Guide to the Simple Management Protocol, SNMPv2, RMON, and RMON2.2.ed. New
York, USA: M&T Books, 1997.
2- TANENBAUM, Andrew. Redes de Computadores. Primeira Edição.
Editora Campus, 1994.
3- ROSE, M.; MCCLOGHRIE, K; Structure and Identifications of
Management Information for TCP/IP-based Internets- RFC1155.
4- STALLINGS, W.; SNMP, SNMPv2, SNMPv3, RMON AND RMON2-
Pratical Network Management. 3.ed. USA:Addison- Wesley, 1998.
5- TANENBAUM, A.S.; Computer Networks.3.ed. USA: Prentice Hall, Inc.
1996.
6- Cisco. Disponível por WWW em http://www.cisco.com (dez.2003).
7- Cervieri, A.; Gerenciamento de Controladores Programáveis através de
SNMP (Trabalho de diplomação apresentado na UFRS, dez.1999).
8- IPSwitch. Disponível por WWW em http://www.ipswicth.com (dez.2003).