protocolo de gerenciamento

8/7/2019 protocolo de gerenciamento

1/86

UNIVERSIDADE FEDERAL DE GOISESCOLA DE ENGENHARIA ELTRICA E DE COMPUTAO

PROJETO FINAL DE CURSO

ANLISE DE PROTOCOLOS NA REA DEGERNCIA DE REDES (SNMP/RMON)

Clayton Arajo Freitas

Joo Wesley Alves Monteiro

Orientador: Prof MSc. Carlos Galvo Pinheiro Jr.


2/86

I

Goinia2004

CLAYTON ARAJO FREITASJOO WESLEY ALVES MONTEIRO

ANLISE DE PROTOCOLOS NA REA DE GERNCIA DEREDES (SNMP/RMON)

Projeto final apresentado ao Curso deGraduao em Engenharia de Computao daUniversidade de Gois, para obteno dottulo de Engenheiro de Computao.rea de concentrao: Gerncia de Redes.Orientador: Prof Carlos Galvo Pinheiro Jr.


3/86

II

Goinia2004

CLAYTON ARAJO FREITASJOO WESLEY ALVES MONTEIRO

ANLISE DE PROTOCOLOS NA REA DEGERNCIA DE REDES (SNMP/RMON)

Projeto final apresentado e aprovado em Dezesseis de

Janeiro de 2004, pela Banca Examinadora composta por:

______________________________________Prof. MSc. Carlos Galvo Pinheiro Jr

Presidente da Banca

_______________________________________Prof. Dr. Gelson da Cruz Jr

_______________________________________Eng. Eletricista Alex da Rosa


4/86

III

Dedicamos esse trabalho aos nossos pais, amigos e professores peloincentivo e apoio, sem os quais esta obra no se realizaria.


5/86

IV

AGRADECIMENTOS

Ao professor e orientador deste projeto final de curso, Carlos Galvo Pinheiro Jrpeloincentivo, motivao e flexibilidade no decorrer de todo o trabalho.

Aos nossos colegas de graduao Luciano de Oliveira Costa, Giscar Fernandes V.

de Paiva,pelo auxlio na obteno de material para efetuar os nossos estudos.Ao professor Ubaldo Eleutrio da Silva, professor do CEFET-Gois, que nosofereceu 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 contriburam

para a realizao desse trabalho.


6/86

V

SUMRIO

LISTA DE ABREVIATURAS-----------------------------------------------------------------------VII

LISTA DE FIGURAS--------------------------------------------------------------------------------VIIILISTA DE TABELAS---------------------------------------------------------------------------------IX

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

INTRODUO-------------------------------------------------------------------------------------------11

CAPTULO 1TEORIA SOBRE GERENCIAMENTO DE REDES------------------------13

1.1 TIPOS DE GERENCIAMENTO--------------------------------------------------------------141.1.1 GERENCIAMENTO DE FALHAS-----------------------------------------------------------141.1.2 GERENCIAMENTO DE CONTABILIDADE----------------------------------------------151.1.3 GERENCIAMENTO DE CONFIGURAO-----------------------------------------------151.1.4 GERENCIAMENTO DE DESEMPENHO--------------------------------------------------161.1.5 GERENCIAMENTO DE SEGURANA---------------------------------------------------161.2 AXIOMAS DE GERENCIAMENTO DE REDES---------------------------------------------17

CAPTULO 2SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)-----------202.1HISTRICO DA GERNCIA DE REDES TCP/IP--------------------------------------212.2 DESENVOLVIMENTO DO SNMP------------------------------------------------------252.3 ARQUITETURAS DE GERENCIAMENTO--------------------------------------------302.4 O MODELO DE GERENCIAMENTO DA INTERNET-------------------------------332.5 DEFINIO DOS RELACIONAMENTOS ADMINISTRATIVOS----------------352.6 OPERAES SNMP------------------------------------------------------------------------372.7 FORMATO DAS MENSAGENS SNMP-------------------------------------------------392.8 PROXIES-------------------------------------------------------------------------------------412.9 AS VANTAGENS DO SNMP-------------------------------------------------------------422.10 AS DESVANTAGENS DO SNMP-----------------------------------------------432.11 MTODOS DE IMPLEMENTAO----------------------------------------------442.12 CONSTRUO DE AGENTES SNMP-------------------------------------------44

2.12.1 TCNICAS DE CONSTRUO USANDO SOCKETS--------------------452.12.2 TCNICAS DE CONSTRUO USANDO PROXY-----------------------462.12.3

TCNICAS DE CONSTRUO USANDO AGENTE ESTENDIDO---46


7/86

VI

CAPTULO 3 RMON (REMOTE MONITORING)----------------------------------------47

3.1 OBJETIVOS DO PROTOCOLO RMON--------------------------------------------------49

3.1.1 CONTROLE DE MONITORES REMOTOS-------------------------------------503.1. 2 MLTIPLOS GERENTES---------------------------------------------------------51

3.2 RMON1 E RMON2-------------------------------------------------------------------------523.3 REMOTE MONITORING INFORMATION BASE (RMON-MIB)----------------53

3.3.1 GRUPOS DA RMON1-MIB-----------------------------------------------------533.3.2 GRUPOS DA RMON2-MIB-----------------------------------------------------54

3.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON----------------------------------55

CAPTULO 4 MANAGEMENT INFORMATION BASE (MIB)------------------------564.1 ESTRUTURA DA MIB--------------------------------------------------------------------58

4.2 DEFINIO DE OBJETOS---------------------------------------------------------------62

4.3 DEFINIES PARA SMI-----------------------------------------------------------------62

CAPTULO 5 ESTUDO DE CASO-------------------------------------------------------------65

5.1 APLICAO COM CLP------------------------------------------------------------------66

5.2 ARQUITETURA DE UM CLP-----------------------------------------------------------66

5.3 PROPOSTA DE MIB----------------------------------------------------------------------665.4 TRAPS---------------------------------------------------------------------------------------67

5.5 ALTERNATIVAS DE IMPLEMENTAO DO AGENTE-----------------------67

5.5.1 AGENTE NO PRPRIO CLP-------------------------------------------------675.5.2 AGENTE COMO UM PROXY-----------------------------------------------68

5.6 IMPLEMENTAO DO SOFTWARE AGENTE----------------------------------69

5.7 OBSERVAES LEVANTADAS------------------------------------------------------70

CAPTULO 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

CONCLUSO--------------------------------------------------------------------------------------------84

REFERNCIAS BIBLIOGRFICAS----------------------------------------------------------------75


8/86

VII

Lista de Abreviaturas

API - Aplication Programming Interface

CLP - Controlador Lgico Programvel

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 BasedSNMPv3 - 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


9/86

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 Possvel configurao 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-------------------------------------------------------------------------46Figura 2.12.3 Uso do agente estendido---------------------------------------------------------------46

Figura 4.1.1 rvore da MIB construda pelo MIB Browser------------------------------------58

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

Figura 5.5.2 Implementao usando a pilha TCP/IP---------------------------------------------67

Figura 5.5.3 Implementao com agente do tipo proxy-----------------------------------------68

Figura 5.6.1 Mdulos usados para interfacear com o CLP-------------------------------------69

Figura 6.4.1 Grfico 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--------------------------------------------------------------------------80Figura 6.5.5 Guia Alerts----------------------------------------------------------------------------80

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

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


10/86

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


11/86

X

RESUMO

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

tipos de usurios, foi necessrio ampliar as ferramentas de superviso de rede,

favorecendo a agilidade, produtividade, segurana e portabilidade nas operaes.

Sendo assim, este trabalho apresenta um estudo sobre a origem,

desenvolvimento e utilizao de protocolos de gerncia, em especfico: SNMP e

RMON. Alm 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 servio.

Nesse trabalho apresentado um estudo que vai de encontro com os anseios da

indstria: aplicao do SNMP utilizando ferramentas de um controlador lgico-

programvel (CLP).


12/86

INTRODUO

As redes de computadores e sistemas distribudos esto se tornando cada vez mais

importantes dentro das organizaes comerciais, governamentais e institucionais. Para

essas organizaes, os recursos disponibilizados pela rede e suas aplicaes suportadas so

indispensveis, embora problemas ocorram seguidamente. A deteco dos problemas e a

administrao de todos os recursos so tarefas complexas, que demandam grandes esforos

dos gerentes e administradores de rede. Desta forma, so fundamentais as ferramentas

computacionais que auxiliem na gerncia e administrao das redes.

Essas ferramentas se baseiam na arquitetura gerente/agente, onde o gerente envia

requisies ao agente, que atua diretamente nos recursos gerenciados. Este ciclo de

gerncia pode ser resumido em observao (recuperar valores e eventos) e controle (gerar

eventos e alterar valores). As interfaces pelas quais o administrador realizar essas aes, a

partir da estao gerente, so de extrema importncia, sendo, geralmente, orientadas a texto

ou grficos bidimensionais.

Este trabalho de projeto final tem como objetivo propor um estudo dos protocolos

de Gerncia de Redes, especificamente o SNMP e o RMON.

Alguns passos a serem seguidos no decorrer deste trabalho so o estudo do estado

da arte em gerncia de rede protocolo SNMP (Simple Network Management Protocol),base de gerncia MIB-II (Management Information Base II) e o protocolo RMON (Remote

Network Monitoring) e a elaborao do texto.

Quando a rede ARPANET se tornou a rede mundial, com a interconexo de

equipamentos heterogneos cada vez mais comuns, ferramentas de gerncia padres se

tornaram necessrias. At aquele momento, quando alguma atividade de gerncia era

necessria, o gerente deveria ir at o equipamento relevante e realizar algum tipo de teste

diretamente nele, ou atravs de ferramentas proprietrias, fazer alguma operaoremotamente. Mas as ferramentas proprietrias eram teis somente para um certo

equipamento de certos fabricantes, no se aplicando num contexto geral. E ter que ir

pessoalmente aos equipamentos era invivel, visto que a rede crescia continuamente.

Ento algumas RFCs ( Request For Comment) foram propostas ao IAB (Internet

ArchitectureBoard) sem muito xito, at que a RFC 1157, de 1990, props o protocolo

SNMP (Simple Network Management Protocol), mais tarde amplamente adotado como

padro de gerncia em redes TCP/IP (Transmission Control Protocol /Internet Protocol).


13/86

12

No tendo muitas ambies, o protocolo deveria ser simples e suportar operaes simples,

baseado na arquitetura cliente/servidor, ou especificamente, gerente/agente.

O dispositivo que contm o gerente, localizado numa mquina que oferea um certo

poder de processamento, memria 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 operao dar a devida resposta ao

requisitante. Segundo esse paradigma, a tarefa de gerncia de rede se baseia em duas aes

tpicas: observao e controle distncia.

Desta forma, a interface do gerente decisiva e importante. Assim como as tarefas

foram se tornando complexas, a exigncia por efetivamente visualizar, monitorar e

manipular os recursos gerenciados se torna essencial. As interfaces foram se tornandogrficas, o uso de cones que representavam os diversos equipamentos (cones para

estaes, para hubs, roteadores) auxiliava na identificao rpida dos equipamentos. Logo

imagens mais realsticas passaram a serem usadas, quase representando imagens

fotogrficas dos equipamentos.

O objetivo desta pesquisa fazer um estudo sobre a gerncia de rede, contemplando

o interfaceamento mais realstico do operador humano com equipamentos remotos, como

se estivesse local a eles, com nfase s aes manifestadas em operaes do protocoloSNMP e RMON.

Desta maneira, alguns objetivos intermedirios so:

Estudo do estado da arte em gerncia de rede;

Estudo do protocolo SNMP e das MIB II, e RMON e MIBs.

Utilizou-se para este trabalho uma metodologia que consiste na identificao do

contexto, estudando as tecnologias envolvidas para o SNMP, para as MIBS, e para o

RMON.Foi feita ainda, uma pesquisa sobre a manipulao dos objetos gerenciveis,

utilizando os protocolos SNMP e RMON, para permitir a interao entre eles na rede.


14/86

13

CAPTULO 1

TEORIA SOBRE GERENCIAMENTO DE REDES

No captulo 1, tem-se uma abordagem acerca da teoria que abrange a

gerncia de redes, estudando as suas subclasses. Sero discutidos os axiomas

da gerncia de redes, tendo os passos bsicos para operar eficazmente no

processo. So definidos, tambm, os componentes bsicos de um sistema que

utiliza o SNMP, tais como o Gerente e o Agente.


15/86

14

O contnuo crescimento em nmero e diversidade dos componentes das redes de

computadores tem tornado a atividade de gerenciamento da rede cada vez mais complexa.

Duas causas principais tm tornado rduo o trabalho de isolamento e teste de problemas:

Diversidade dos nveis do pessoal envolvido: tcnicos, gerentes e

engenheiros;

Diversidade nas formas de controle e monitorao: produtos cada vez mais

complexos, cada fornecedor oferecendo ferramentas prprias de controle e monitorao.

Para expandir melhor os meios de pesquisa e atuao na rea de gerncia, a ISO

dividiu o gerenciamento de redes em cinco reas funcionais:

Gerenciamento de falhas;

Gerenciamento de configurao; Gerenciamento de segurana;

Gerenciamento de performance e

Gerenciamento de contabilizao.

Muitas vezes as reas funcionais possuem funes de gerenciamento que se

sobrepem, isto , so utilizadas no somente uma, mas at mesmo em vrias reas de

gerenciamento, apesar de terem finalidades em cada uma. Por outro lado, algumas funes

servem de suporte para as funes das outras reas.

1.1 TIPOS DE GERENCIAMENTO

1.1.1 GERENCIAMENTO DE FALHAS

A gerncia de falhas tem a responsabilidade de monitorar os estados dos recursos,

dar manuteno a cada um dos objetos gerenciados, e tomar decises para restabelecer as

unidades do sistema que venham a dar problemas.

As informaes que so coletadas sobre os vrios recursos da rede podem serusadas em conjunto com um mapa desta rede, para indicar quais elementos esto

funcionando, quais esto em mau funcionamento, e quais no esto funcionado.

Opcionalmente, pode-se gerar um registro das ocorrncias na rede, um diagnstico

das falhas ocorridas e uma relao dos resultados deste diagnstico com as aes

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 atravs do


16/86

15

monitoramento das taxas de erros do sistema, e da evoluo do nvel de severidade gerado

pelos alarmes (funo de relatrio alarme), que permitem a emisso das notificaes de

alarme ao gerente, que pode definir as aes necessrias para corrigir o problema e evitar

as situaes mais crticas.

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 utilizao

daqueles recursos. Outras consideraes incluem informaes dos custos dos usurios e

recursos gastos, estipulando limites e incorporando informaes de tarifas em todo oprocesso de contabilidade.

No mundo de hoje, contabilidade significa tratar com pessoas usando os reais

recursos de rede com despesas de operao real. Exemplos destes custos incluem uso do

espao em disco e dados armazenados, despesas de telecomunicaes para acesso a dados

remotos e taxas de envio de e-mail.

Pode-se tambm usar o gerenciamento de contabilidade para determinar se a

utilizao dos recursos da rede esto aumentando com o crescimento, o que deve indicar anecessidade de adies e reajustamentos num futuro prximo.

1.1.3 GERENCIAMENTO DE CONFIGURAO

O objetivo da gerncia de configurao o de permitir a preparao, a iniciao, a

partida, a operao contnua e a posterior suspenso dos servios de interconexo entre os

sistemas abertos, tendo ento, a funo de manuteno e monitoramento da estrutura fsicae lgica de uma rede, incluindo a verificao da existncia dos componentes e a

verificao de interconectividade entre estes componentes.

A gerncia de configurao correspondente a um conjunto de facilidades que

permitem controlar os objetos gerenciados, identific-los, coletar e disponibilizar dados

sobre estes objetos para as seguintes funes:

Atribuio de valores iniciais aos parmetros de um sistema aberto;

Incio e encerramento das operaes sobre os objetos gerenciados;


17/86

16

Alterao da configurao do sistema aberto e

Associao de nomes a conjuntos de objetos gerenciados.

1.1.4 GERENCIAMENTO DE DESEMPENHO

Na gerncia de desempenho tem-se a possibilidade de avaliar-se o comportamento

dos recursos num ambiente de gerenciamento OSIpara verificar se este comportamento

eficiente, ou seja, preocupa-se com o desempenho corrente de rede, atravs de parmetros

estatsticos como atrasos, vazo, disponibilidade e o nmero de retransmisses realizadas.

O gerenciamento de desempenho um conjunto de funes responsveis por

garantirem que no ocorram insuficincias de recursos quando sua utilizao se aproximarda capacidade total do sistema.

Para atingir estes objetivos, deve-se monitorar as taxas de utilizao dos recursos,

as taxas em que estes recursos so pedidos e as taxas em que os pedidos a um recurso so

rejeitados. Para cada tipo de monitoramento, define-se um valor mximo aceitvel

(threshold), um valor de alerta, e um valor em que se remove a situao de alerta.

Definem-se trs modelos para atender aos requisitos de monitoramento de uso dos

recursos dos sistemas: Modelo de Utilizao: Prov o monitoramento do uso instantneo de um

recurso;

Modelo de Rejeio: Prov o monitoramento da rejeio de um pedido de

um servio e

Modelo de Taxa de Pedido de Recursos: Prov o monitoramento dos

pedidos do uso de recursos.

1.1.5 GERENCIAMENTO DE SEGURANA

O objetivo do gerenciamento de segurana o de dar subsdios a aplicaes de

polticas de segurana, que so essncias para que uma rede baseada no modelo OSIseja

corretamente configurada, protegendo os objetos contra de acessos indevidos. Deve-se

providenciar um alarme ao gerente da rede sempre que se detectarem eventos relativos

segurana do sistema.


18/86

17

As informaes de gerenciamento de segurana so armazenadas numa MIB

especial, a qual deve dar apoio as trs categorias de atividades de gerenciamento de

segurana 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:

O trfego devido s informaes de gerenciamento no deve aumentar

significativamente o trfego da rede;

O agente de protocolo no dispositivo gerenciado, no deve aumentarsignificativamente o resultado de processamento a ponto de prejudicar a funo principal

daquele dispositivo.

Para se montar uma plataforma de gerenciamento de redes, necessrio observar

qual o pacote de softwares que oferece as funcionalidades bsicas para gerenciamento de

vrios dispositivos diferentes, tendo como objetivo, oferecer funcionalidades genricas

para gerenciamento padro dos vrios dispositivos.

Adicionalmente se pode citar, como forma de componentes funcionais teis plataforma de gerncia o uso de ferramentas grficas, uma API ( Aplication Programming

Interface) de programao e segurana 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 eficincia na realizao destas tarefas est diretamente ligada presena de

ferramentas que as automatizem e de pessoal qualificado. Atualmente existem no mercado

diversos tipos de ferramentas que auxiliam o administrador nas atividades degerenciamento. Estas ferramentas podem ser divididas em quatro categorias:

Ferramentas de nvel fsico, que detectam problemas em termos de cabos e

conexes de hardware;

Monitores de rede, que se conectam as redes monitorando o trfego;

Analisadores de rede, que auxiliam no rastreamento e correo de

problemas encontrados nas redes;


19/86

18

Sistemas de gerenciamento de redes, os quais permitem a monitorao e

controle de uma rede inteira a partir de um ponto central.

Dentre a gama de solues possveis 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 informaes necessrias ao seu gerenciamento.

Evidentemente preciso montar um banco de dados, que ser gerente da rede,

contendo informaes necessrias para apoiar o diagnstico e na busca de solues para

problemas da rede. Isto envolve esforo para identificar, rastrear e resolver situaes de

falhas.

Como o tempo de espera do usurio pelo restabelecimento do servio deve ser o

menor possvel, tudo isto deve ser feito eficientemente.Os sistemas de gerenciamento de redes apresentam a vantagem de ter um conjunto

de ferramentas para anlise e depurao da rede. Estes sistemas podem apresentar tambm

uma srie de mecanismos que facilitam a identificao, notificao e registro de

problemas, como por exemplo:

Alarmes que indicam, atravs de mensagens ou bips de alerta,

anormalidades na rede;

Gerao automtica de relatrios contendo as informaes coletadas; Facilidades para integrar novas funes ao prprio sistema de

gerenciamento;

Gerao de grficos estatsticos em tempo real;

Apresentao grfica da topologia das redes.

Esses so os passos bsicos para poder escolher um sistema confivel e que

contribua para o gerenciamento de uma rede:

Fazer o inventrio dos dispositivos gerenciveis na rede; Determinar a rea funcional de gerenciamento;

Escolher as aplicaes de gerncia para os dispositivos;

Escolher a plataforma de gerenciamento de acordo com as aplicaes

selecionadas.

Em redes IP, o sistema de gerenciamento segue o modelo gerente-agente, onde o

GERENTE o prprio sistema de gerenciamento de toda a parte de configurao ligada s

aplicaes e ao usurio, e o AGENTE um software que deve ser instalado nos


20/86

19

equipamentos gerenciados e que servem para armazenar a informao de gerenciamento

local e encaminhar essa informao ao GERENTE via SNMP (Simple Network

Management Protocol). Trocando em midos, a tarefa do agente responder as

requisies feitas pelo gerente em relao ao equipamento no qual o agente est instalado.

Esta interao viabilizada pelo protocolo de gerenciamento SNMP, o qual como uma

linguagem comum utilizada exclusivamente para a troca de informaes de gerenciamento.

Dessa forma, o gerente consegue conversar com qualquer mquina que fale SNMP,

independente do tipo de hardware e sistema operacional. O conjunto de informaes ao

qual o gerente pode fazer requisies ou alteraes denominado de Management

Information Base (MIB). Para melhor compreenso, veja a Figura 1.2.1.

O protocolo de gerenciamento SNMP constitui atualmente um padro operacional

"de fato", e grande parte do seu sucesso se deve a sua simplicidade, sendo um protocolo

send/receive com apenas quatro operaes. Outro aspecto importante a sua capacidade de

gerenciar redes heterogneas constitudas 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, estaes de trabalho SUN e outros

tipos de computadores.

As aplicaes de gerenciamento utilizam o SNMP para:

Fazerpolling nos dispositivos de rede e coletar dados estatsticos para

anlise em tempo real.

Receber um conjunto limitado de notificaes de eventos significativos ou

mensagens trap, a qual informa sobre algum evento importante ocorrido.

Reconfigurar dispositivos de rede.

Figura 1.2.1 - Sistema de gerenciamento SNMP


21/86

20

CAPTULO 2

SNMP (SIMPLE NETWORK MANAGEMENT

PROTOCOL)

No presente captulo ser feita uma discusso a respeito das razes histricas

que inspiraram o surgimento do SNMP, discutindo-se sua arquitetura,

formato do quadro de mensagens, alm das vantagens e desvantagens. A

construo de Agentes tambm ser debatida no contexto.


22/86

21

2.1 HISTRICO DA GERNCIA DE REDES TCP/IP

De forma a fazer um breve histrico da gerncia de redes em TCP/IP remonta-se s

origens do prprio 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, alm disso, buscavam uma

forma de comunicao mais confivel do que as vulnerveis 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 comunicaes 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 criao daprecursora da Internet, a ARPANET.

AARPANETcresceu 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 daARPANETseria a

interoperabilidade. Diferentes hosts de diferentes fabricantes deveriam ser conectados,

precisando de sistemas de suporte troca de arquivos, interao entre os terminais e hosts.

O problema se tornou ainda maior quando a ARPANET se tornou o centro dacrescente Internet, uma coleo 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 dcada de 70, deram origem aos atuais

protocolos da pilha TCP/IP. Estes protocolos foram considerados como padres oficiais

para o Internet Architecture Board(IAB) atravs de Requests For Comments (RFCs).

Finalmente, os protocolos fundamentais dessa pilha TCP/IP nasceram de padresutilizados em tecnologias militares.

O TCP/IP preencheu as exigncias doDoD e se tornou o padro dessa organizao.

Um aspecto interessante e inesperado foi o crescimento do TCP/IP em aplicaes no

militares. Este crescimento comeou a se intensificar na metade da dcada de 80,

exatamente quando estavam sendo feitos esforos para desenvolver um consenso

internacional em torno dos protocolos desenvolvidos pelo OSI. Afirmava-se que o OSI se

tornaria o responsvel pela completa interoperabilidade dos sistemas, mas o TCP/IP


23/86

22

cresceu muito nos ltimos anos e continuou crescendo a cada dia, ainda mais depois da

popularizao da Internet.

O TCP/IP se tornou to mais popular no meio comercial por vrios motivos,

incluindo o fato de j ser um conjunto de protocolos maduros, j profundamente testados,

que provem a interoperabilidade dos sistemas e com um alto nvel de funcionalidade. J o

OSI demorou demais para apresentar uma verso 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 implementao muito difcil

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 relao gerncia 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 dcada de 70 no 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 utilizadano incio da Internet para a gerncia da rede. Disponvel 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 informao a respeito de problemas na rede.

Uma das caractersticas 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 possvel a comunicao entre duas entidades da rede, isto conseguido

porque quando uma mensagem do tipo echo recebida, a entidade obrigada a retornar ocontedo 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

caractersticas 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 opes adicionais como o nmero de pedidos e o

nmero de tentativas de solicitao, o PING pode ter vrias funes. Como exemplos tem-


24/86

23

se: determinar se um equipamento de rede pode ser alcanado, verificar se uma rede pode

ser alcanada e verificar as operaes 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 dcada de 80, o PING e outras ferramentas tambm 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 nmero de hosts na Internet

causou tambm um grande aumento na complexidade, com um nmero muito maior de

sub-redes, de entidades a serem gerenciadas e tambm entidades que tm responsabilidades

por gerenciar parte da Internet.Desta forma, com uma rede com propores cada vez maiores, era impossvel

deixar a cargo de poucos o seu gerenciamento, e ainda com ferramentas simples. Era

necessrio 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 trs outras abordagens surgiram:

High-Level Entity Management System (HEMS): generalizao de um dos primeiro protocolos de gerenciamento de rede usado na Internet o Host Monitoring

Protocol(HMP);

Simple Network Management Protocol (SNMP): surgiu como um

aperfeioamento do Simple Gateway Management Protocol(SGMP);

CMIP over TCP/IP (CMOT): tentativa de incorporar o mximo possvel do

protocolo (CMIP Commom Management Information Protocol), servios e estrutura do

banco de dados padronizado pela ISO para o gerenciamento de rede. No incio 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 razovel perodo de tempo as redes TCP/IP seriam

substitudas por protocolos baseados no OSI e dessa forma no se queria investir por um

longo perodo de tempo em protocolos que seriam abandonados, assim, o SNMP teria

apenas as funcionalidades mnimas para suportar o gerenciamento das redes TCP/IP e

funcionar tambm como uma experincia na rea da gerncia de rede. O SNMP foi


25/86

24

escolhido, em detrimento do HEMS que tinha muito mais funcionalidades, exatamente

pelo motivo de no se querer gastar esforo extra em uma arquitetura de rede que no

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

transio seria simples e rpida. De forma a solidificar essa estratgia, foi definido que

ambos os protocolos, CMOT e SNMP, usariam o mesmo banco de dados de objetos

gerenciados, ou seja, os mesmos conjuntos de variveis de controle e de formatos de

dados, desta forma uma nica estrutura das informaes SMI (Structure of Management

Information) e base de informaes MIB.

Entretanto, ficou claro que seria impraticvel manter a compatibilidade de objetos

entre os dois protocolos. No gerenciamento OSI, os objetos so vistos como entidadessofisticadas, com atributos, procedimentos associados, capacidade de notificao e outras

caractersticas complexas. J no SNMP, para mant-lo simples, os objetos no so

realmente o que se considera objeto do ponto de vista da orientao a objetos, mas so

apenas variveis com algumas caractersticas bsicas, como tipos de dados, se so somente

leitura ou tem acesso de escrita entre outras. Dessa forma foi decidido pela IAB, que a

idia de uma SMI/MIB comum para os dois protocolos no era vivel, e o

desenvolvimento do SNMP e CMOT poderia seguir independentemente.O SNMP um protocolo no orientado conexo; nenhuma ao prvia

necessria no envio de mensagens; nenhuma ao necessria aps as mensagens terem

sido enviadas. Isso tem como conseqncia a perda de garantia que as mensagens do

protocolo chegaro ao destino. Porm, na prtica, a maioria das mensagens entregue, e

aquelas que no so podem ser retransmitidas. Esta caracterstica impe mais robustez ao

sistema, visto que como no existe a preocupao com a orientao conexo, nem o

gerente, nem o sistema gerenciado necessitam um do outro para operar.O SNMP um protocolo da camada de aplicao designado para facilitar a troca de

informaes 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 preciso uma possvel

expanso 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


26/86

25

acesso e de informaes. Esta popularizao se deve ao fato de que o SNMP um

protocolo relativamente simples, porm suficientemente poderoso para resolver os difceis

problemas apresentados quando se tenta gerenciar redes heterogneas.

2.2 DESENVOLVIMENTO DO SNMP

Assim que se decidiu pela libertao do desenvolvimento do SNMP das amarras da

compatibilidade com o OSI, seu progresso foi similar ao do TCP/IP. Rapidamente o SNMP

se tornou disponvel em vrios equipamentos de vrios fabricantes, tornando-se o

protocolo de gerenciamento da escolha da maioria dos usurios, sendo praticamente um

padro. Enquanto o TCP/IP ignorava as predies referentes a sua curta vida e continuava

a crescer mais ferozmente ainda, tambm o SNMP parecia se tornar a escolha da maioria,enquanto que o desenvolvimento da gerncia de rede pelo OSI continuava atrasado.

O SNMP mais bsico j est sendo usado em larga escala, praticamente todos os

fabricantes de computadores, estaes de trabalho, pontes, roteadores, hubs, etc. oferecem

o bsico SNMP. Segue ainda o trabalho em SNMP sobre OSI e outras pilhas de protocolos

no TCP/IP, alm dos tantos avanos que se tem feito ao SNMP em vrias direes.

Uma das inovaes mais significativas pode-se afirmar que foi a criao da

capacidade de gerenciamento remoto para SNMP. O monitoramento remoto, ou RMON(Remote Monitoring) tem em sua definio a especificao da forma de monitorar as sub-

redes como um nodo, e no apenas como equipamentos ou sub-redes individualmente. O

RMON visto pelos usurios e fabricantes como uma extenso essencial do SNMP.

Alm do RMON, vrias extenses a MIB bsica do SNMP tm sido criadas.

Algumas dessas extenses so independentes de fabricantes sendo padres adotados

internacionalmente e que foram acrescentadas a MIB original, como por exemplo, Token

RingeFDDI. Outras so informaes especificas de certos fabricantes e so consideradasextenses privadas da MIB. Estas extenses no acrescentam novas tecnologias ao SNMP,

so apenas incrementos no conjunto de informaes 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.


27/86

26

RFC Data Ttulo

1155 Maio, 1990 Structure and Identification of Management Information

(SMI) for TCP/IP-basedInternet

1157 Maio, 1990 A Simple Network Management Protocol (SNMP)

1212 Maro, 1991 Concise MIB Definitions

1213 Maro, 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

aplicaes maiores e mais complexas. Apesar de ainda ser extremamente til para um

grande nmero de aplicaes, 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 damelhor maneira possvel.

Um dos grandes problemas do SNMP a segurana. No existe forma de autenticar

a origem de uma mensagem SNMP. A existncia do nome de comunidade no garante

absolutamente nada em matria de segurana, visto que ela no criptografada, qualquer

entidade poderia capturar um pacote e obter o nome de comunidade atualmente utilizado

pelo sistema. Devido a essa deficincia, muitos fabricantes decidiram por no implementar

a mensagem set, prevenindo a modificao de valores no equipamento gerenciado. Istodiminua ainda mais as j reduzidas capacidades do SNMP, tornando-se apenas uma

ferramenta de monitoramento. Ento, para contornar esse problema, um conjunto de RFCs

foram lanadas a partir de julho de 1992 tentando definir um secure SNMP.

Entretanto, o SNMP seguro ainda possua vrias deficincias. Assim, nesse mesmo

ano, uma nova proposta surgiu, definida como Simple Management Protocol (SMP).

Vrios avanos foram feitos em relao ao SNMP, so eles:

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


28/86

27

O SNMP foi criado para a gerncia de qualquer tipo de recurso e no

apenas para recursos de rede. Ele pode ser utilizado para o gerenciamento de aplicaes, de

sistemas e comunicao gerente-gerente;

Manteve a simplicidade, permitindo que fossem criadas implementaes

pequenas e rpidas. Ainda acrescentou-se a capacidade de se transferir uma grande

quantidade de informaes de gerenciamento de uma vez;

Incorporou os recursos de segurana encontrados no SNMP seguro;

Foi projetado para ser executado sobre as pilhas de protocolo TCP/IP, e

outras arquiteturas de comunicao. Pode operar em conjunto com plataformas SNMP j

instaladas, utilizando apenas parte de seus recursos.

Aps a publicao do SNMP seguro preferiu-se fazer uma nica transio entre oSNMP j existente e uma segunda verso do SNMP que incorporasse os avanos em

termos de funcionalidade e tambm os aspectos de segurana presentes no SNMP seguro e

no SMP. Grupos de trabalho foram criados, e em maro de 1993 foi lanada a nova verso

do SNMP, denominada SNMPv2.

O SNMPv2 incorpora novas caractersticas e funcionalidades verso anterior.

Quanto definio da MIB e de sua estrutura, foram acrescentados novos tipos de dados,

como tipos inteiros com um maior nmero de bits. A macro que define os objetos da MIBtambm foi estendida, e as clusulas de TYPE-NOTATION e STATUSforam revisadas.

A verso 2 do SNMP manteve os tipos de pacotes da verso 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 aperfeioamento ao GetNextRequest. Ela funciona como se fossem

executados vrios GetNextRequestem uma nica PDU, alterando apenas a sintaxe de dois

campos, o campoError-status passa a serNon-Repeaters eError-Index passa a serMax-Repetitions.

A mensagem de InformRequest dedicada a comunicao gerente-gerente, sendo

utilizada para a transmisso de informaes que sejam locais a um gerente.

Para a PDU deReportno existe uma definio conhecida. Sabe-se que as citaes

em relao a essa PDU so acompanhadas do seguinte comentrio:


29/86

28

O uso da semntica que precisa da PDU de Reportno so definidas. Qualquer

ferramenta de administrao baseada em SNMP que faa uso desta PDU deve definir seu

uso e sua semntica.

Depois de alguns anos de experincia com o SNMPv2 se fez reviso de suas

especificaes, fazendo-se a retirada dos aspectos de segurana do SNMPv2, deixando

apenas algumas modificaes. Essa nova reviso do SNMP utilizou-se do conceito de

comunidade, empregado no SNMPv1, sendo, portanto, renomeado para SNMPv2 baseado

em comunidade ou SNMPv2c.

RFC Data Ttulo

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 SNMPv21908 Janeiro, 1996 Coexistence Between Version 1 and 2 of the

Internet-Standard Network Management Framework

Esta eliminao dos aspectos de segurana do SNMPv2 foi na verdade um

retrocesso. Os grupos de trabalho pela anlise do SNMP foram surpreendidos pela falta de

consenso em relao segurana e seu prazo havia se esgotado. Na necessidade do

lanamento dessa nova verso do SNMP optou-se por omitir as caractersticas desegurana, reforando e aprimorando certas caractersticas funcionais e mantendo os

prazos determinados.

De modo a corrigir os problemas de falta de segurana no SNMPv2c, dois grupos

de trabalhos foram organizados, dando origem as especificaes SNMPv2u e SNMPv2*.

Em maro de 1997 foi criado um grupo de trabalho pelo IETF para unificar essas duas

propostas em uma nica nova verso do SNMP, o SNMPv3. Em janeiro de 1998 este

grupo de trabalho deu origem a uma srie de RFCs especificando a nova verso do

Tabela 2 - RFCs relacionadas ao SNMPv2c


30/86

29

protocolo. O SNMPv3 incorpora caractersticas de segurana s funcionalidades j

existentes do SNMPv1 e SNMPv2.

RFC Data Ttulo

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 InternetNetwork Management Framework

O SNMPv3 no substitui o SNMPv1 e o SNMPv2, ele apenas apresenta

funcionalidades de segurana s duas verses anteriores do protocolo, dando preferncia 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 cabealho. A Figura 2.2.1

mostra como se d o encapsulamento.

Tabela 3 RFCs relacionadas ao SNMPv3


31/86

30

Dessa forma, o SNMPv3 consegue contornar o problema que existia nas verses

anteriores, acrescentando-se as caractersticas de privacidade, autenticao e controle de

acesso sem que se necessite especificar um protocolo completamente novo, facilitando a

transio dos equipamentos que atualmente j suportam as verses anteriores. Alm disso,

o SNMPv3 definiu uma arquitetura mais modular, especificando quais partes devem ser

implementadas pelos clientes e quais so as responsabilidades dos gerentes, tornando,dessa forma, mais fcil o avano das funcionalidades do protocolo sem a necessidade da

definio de um novo padro, bem como propor estratgias de transio mais claras e

fceis.

2.3 ARQUITETURAS DE GERENCIAMENTO

O modelo de gerncia utilizado nas redes TCP/IP inclui os seguintes elementos

chaves: Estao de gerenciamento;

A base de informaes de gerenciamento, MIB (Management Information

Base);

O protocolo de gerncia.

A estao de gerenciamento normalmente um nico equipamento, ou tambm

pode estar implementado em um ambiente distribudo ou hierrquico. De qualquer forma, a

estao de gerenciamento serve como a interface entre o sistema de gerenciamento da rede

Figura 2.2.1 - Arquitetura do protocolo SNMPv3


32/86

31

(automatizado) e o gerenciamento humano. Entre o mnimo de funcionalidade que deve ser

fornecido pela estao de gerenciamento pode-se citar:

Um conjunto de aplicaes para anlise de dados, recuperao de falhas,

entre outras;

Uma interface (grfica) pela qual o gerente da rede pode monitorar e

controlar o estado da rede;

Capacidade de traduzir as necessidades do gerente de rede na forma dos

atuais meios de monitorao e controle dos elementos remotos da rede;

Manter e fornecer acesso a um banco de dados de informaes extradas

das MIBs de todas as entidades gerenciveis na rede.

As definies do SNMP abordam somente os dois itens finais desta lista, deixandoo conjunto de aplicaes 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 estao de gerenciamento. O

agente responde por pedidos de informaes e aes por parte da estao gerente (ou das

estaes gerentes) e pode, assincronamente fornecer estao de gerncia, informaesque no foram solicitadas, mas que so vitais.

Os recursos na rede podem ser gerenciados atravs de sua representao como

objetos. Cada objeto essencialmente uma varivel que representa algum aspecto

importante do objeto gerenciado, e o dado contido nesta varivel obtido, ou preenchido,

pelo agente. A coleo desses objetos chamada de Management Information Base (MIB).

A MIB funciona como pontos de acesso no agente para as estaes de gerncia. Estes

objetos so padronizados para cada classe particular de equipamentos, por exemplo,existem MIBs para rotedores, MIBs para pontes, etc. A estao de gerncia executa o

monitoramento da rede atravs da busca dos valores dos objetos da MIB. Da mesma forma,

a estao de gerncia pode causar a execuo de um agente, ou pode modificar as

configuraes de um agente atravs da atribuio de algum valor em um objeto da MIB.

A estao de gerenciamento ligada ao agente de um protocolo de comunicao,

um protocolo de gerncia de rede. O protocolo que utilizado no gerenciamento de redes

TCP/IP o SNMP (Simple Network Management Protocol).


33/86

32

O SNMP foi projetado de modo a ser simples, e o faz em trs formas. Primeiro,

reduzindo o custo de desenvolvimento do software agente, diminuindo o trabalho dos

fabricantes e aumento dessa forma a aceitao do SNMP. Em segundo lugar, ele

extensvel, ou seja, os fabricantes podem estender as caractersticas funcionais do SNMP.

E finalmente, ele separa a arquitetura de gerenciamento da arquitetura dos equipamentos

do hardware, permitindo a coexistncia de vrios equipamentos de diferentes fabricantes.

Na Figura 2.3.1, h uma possvel configurao que pode ser implementada usando o

protocolo SNMP.

O SNMP, que parte do conjunto de protocolos do TCP/IP, est localizado no nvel

de aplicao dessa sute. Ele opera sobre o UDP (User Datagram Protocol).

Para uma estao de gerenciamento de protocolos TCP/IP, est localizado no nvelde aplicao possvel de um ambiente que pode suportar SNMP.

Para uma estao de gerenciamento centralizada, um processo gerente deve

controlar o acesso a uma MIB centralizada (pode estar na mesma estao) e fornecer uma

interface de gerenciamento para o usurio, que nesse caso o gerente da rede. O processo

de gerncia obtm informaes da rede atravs 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

Figura 2.3.1 - Possvel configurao de sistema com SNMP


34/86

33

agente deve implementar o SNMP, UDP e tambm IP. O processo gerente responsvel

por interpretar as mensagens SNMP e controlar os valores da MIB do agente.

Nesse contexto, o gerente pode solicitar informaes do agente utilizando

mensagens deget, que so respondidas pelo agente na mquina remota. Por outro lado, o

agente pode enviar informaes que no tinham sido solicitadas quando da ocorrncia de

algum evento atravs de mensagens de trap.

2.4 O MODELO DE GERENCIAMENTO DA INTERNETComo o TCP/IP, o SNMP um protocolo Internet. Ele uma parte da arquitetura

de gerenciamento da Internet, que baseada na interao de diversas entidades, como se

segue:

Elementos de rede - tambm chamados dispositivos gerenciados, os

elementos de rede so dispositivos de hardware como os computadores, roteadores, e

servidores de terminais que esto conectados a rede;

Agentes - so mdulos de software que residem nos elementos de rede.Eles coletam e armazenam informaes de gerenciamento como o nmero de pacotes de

erros recebidos pelo elemento de rede. So eles que respondem as solicitaes dos

gerentes;

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 emgerentes SNMP usando WebServers e tem como caractersticas:

O browser acessa um gerente que, por sua vez, acessa as informaes via

SNMP;

As informaes so disponibilizadas em pginas HTML pelo gerente

SNMP.

A segunda forma utiliza agentes SNMP com HTTP, tendo como pontos bsicos:

O browser acessar diretamente os recursos;


35/86

34

O WebServer acessar os dados atravs de SNMP;

Os dados so disponibilizados atravs de pginas HTML geradas pelo

agente SNMP;

O recurso gerenciado deve possuir capacidade de processamento para

suportar ao mesmo tempo um WebServer e um agente SNMP.

A MIB neste contexto uma coleo de objetos gerenciados residentes em um

armazenamento virtual de informaes. Colees de objetos gerenciados relacionados so

definidas em mdulos especficos da MIB.

usada uma notao sinttica, ou seja, uma linguagem usada para descrever os

objetos gerenciados da MIB em um formato independente da plataforma. Um uso

consistente da notao sinttica permite que diferentes tipos de computadorescompartilhem informaes. 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

so trocados pelo protocolo de gerenciamento quanto os objetos que ele deve gerenciar.

As definies das regras para descrever as informaes de gerenciamento so

realizadas pela Structure of Management Information (SMI). A SMI definida usando o

ASN.1.Os Network Management Stations (NMS), tambm chamados consoles, so

dispositivos que executam aplicaes de gerenciamento para monitorar e controlar

elementos de rede.

Fisicamente, os NMS so usualmente workstations com CPU velozes, monitores

coloridos de alta definio, memria substancial e um grande espao em disco.

O SNMP o protocolo de gerenciamento usado para transportar informaes de

gerenciamento entre agentes e NMS.Com base nesta arquitetura, o SNMP foi construdo para minimizar a quantidade e

a complexidade das funes necessrias para gerenciar um agente. O paradigma funcional

de controle e monitorao do protocolo foi definido de maneira extensiva, para poder

absorver mais facilmente novos aspectos das operaes de rede e gerenciamento. Alm

disto, esta arquitetura totalmente independente da plataforma dos elementos da rede e dos

NMS.


36/86


37/86

36

A juno de um agente SNMP com algum conjunto arbitrrio de entidades de

aplicao SNMP chamada de comunidade SNMP. Cada comunidade nomeada atravs

de uma cadeia de octetos.

Uma mensagem SNMP, originada por uma entidade de aplicao SNMP que de

fato pertence comunidade SNMP referenciada pela mensagem, chamada mensagem

SNMP autntica. O conjunto de regras existentes para que uma mensagem seja identificada

como uma mensagem SNMP autntica para uma comunidade SNMP qualquer chamado

de esquema de autenticao.

A implementao de uma funo que identifica mensagens autnticas de acordo

com um ou mais esquemas de autenticao chamado servio de autenticao.

Um efetivo gerenciamento das relaes administrativas entre entidades de aplicaoSNMP requer que os servios de autenticao identifiquem mensagens autnticas com

confiabilidade.

Para qualquer elemento da rede, um subconjunto de objetos na MIB que pertence a

este objeto chamado de viso da MIB SNMP. Um elemento do conjunto (READ-ONLY,

READ-WRITE) chamado de modo de acesso SNMP.

A juno do modo de acesso SNMP com a viso da MIB chamada de perfil da

comunidade SNMP. O perfil da comunidade SNMP representa um privilgio de acessoespecfico para variveis em uma MIB especfica. A unio da comunidade SNMP com o

perfil da comunidade chamada de poltica de acesso SNMP. Uma poltica de acesso

representa um perfil de comunidade especfico proporcionado por um agente SNMP de

uma comunidade para outros membros desta comunidade. Todos os relacionamentos

administrativos entre entidades de aplicao SNMP so definidos em termos das polticas

de acesso.

Para toda poltica de acesso SNMP, se o elemento de rede em que o agente SNMPespecificado pela comunidade SNMP reside no contm a viso MIB que o perfil

especifica, ento esta poltica chamada poltica de acesso proxy SNMP. O agente

associado com a poltica de acessoproxy chamado de agenteproxy.

A poltica proxy usualmente definida com a monitorao e o controle dos

elementos de rede que no so endereveis usando o protocolo de gerenciamento e o

protocolo de transporte. Desta forma, um agenteproxy prov uma funo de converso de

protocolo permitindo a uma estao de gerenciamento aplicar um gerenciamento


38/86

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 polticas de controle

de acesso.

2.6 OPERAES SNMP

O SNMP por si s um protocolo de requisio/resposta simples. Os NMS podem

enviar mltiplas requisies sem receber uma nica resposta. Quatro operaes so

definidas no SNMP, as quais incluem as seguintes funes:

Get- permite que o NMS recupere uma instncia de objeto do agente; GetNext- permite que o NMS recupere a prxima instncia 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 operao Get seguida de uma srie de operaes

GetNext;

Set- permite que o NMS modifique valores de uma instncia de objetos em

um agente;

Trap - usado pelo agente para informar assincronicamente o NMS sobrealgum evento.

Essas funes permitem uma forma de acesso muito simples aos dados que so

representados pela MIB. Desta forma, no possvel alterar a estrutura da MIB

adicionando ou apagando instncias de objetos. Tambm no possvel executar

comandos para que uma certa ao seja tomada. Alm disso, como o acesso feito

somente a tipos de dados escalares, ou seja, a objetos-folha da MIB, no possvel obter

todos os objetos de uma tabela em um nico comando. Estas restries limitam ascapacidades do SNMP.

Da mesma forma que uma estao gerente pode enviar comandosgeteset, alm de

recebertraps, de vrias entidades da rede; uma estao gerenciada pode ter um conjunto de

gerentes que solicitam e atualizam informaes. Assim, deve se ter um certo controle de

como feito o acesso a MIB, atravs de trs aspectos fundamentais:

Servio de autenticao: a estao gerenciada pode limitar o acesso a

MIB para apenas certos gerentes que estejam autorizados;


39/86

38

Poltica de acesso: ainda, podem ser dados diferentes nveis de acesso

para diferentes estaes gerentes;

Servio deproxy: uma estao gerenciada pode servir comoproxy entre

as estaes gerente e uma outra estao gerenciada, sendo de sua responsabilidade

implementar os servios de autenticao e controle de acesso.

Esses conceitos so todos relacionados com segurana. 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 caractersticas de segurana. Um agente pode

estabelecer um nmero de comunidades para cada aspecto de segurana desejado. Cada

nome de comunidade tem existncia local ao agente, ou seja, podem existir vrios agentesutilizando o mesmo nome de comunidade sem que essas comunidades tenham qualquer

relao.

O servio de autenticao se preocupa em assegurar que uma comunicao seja

autntica. No caso do SNMP isto pode ser obtido atravs 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, ento ele pode ser

considerado confivel.Definindo uma comunidade, o agente limita o acesso a sua MIB a determinados

conjuntos de gerentes, e ainda, com vrios nomes de comunidades, ele pode fornecer

diferentes categorias de acesso a MIB para cada estao gerente diferente. Assim, dois

aspectos so envolvidos: diferentes vises da MIB podem ser associadas a cada nome de

comunidade.

Os pacotes de mensagem do SNMP so divididos em duas partes. A primeira parte

contm a verso e o nome comunitrio. A segunda parte contm o protocolo de unidade dedados (PDU) do SNMP especificando a operao que ser realizada ("Get", "Set" e outros)

e a instncia de objetos envolvida na operao.

O campo verso usado para garantir que em todos os elementos de uma rede esto

rodandosoftwares baseados na mesma verso do SNMP. O nome comunitrio associa um

ambiente de acesso para um conjunto de NMS usando o nome comunitrio. Um NMS

dentro de uma comunidade pode ser dito existente dentro de um mesmo domnio

administrativo. Como os dispositivos que no conhecem seu prprio nome comunitrio so


40/86

39

excludos das operaes do SNMP, ento o administrador de redes usa o nome comunitrio

como uma forma fraca de autenticao.

O PDU do SNMP tem os seguintes campos:

Tipo PDU - especifica o tipo que o PDU comear transmitindo;

Identificao de requisio - associa as requisies com as respostas;

Variveis ligadas - incluir o dado em um PDU SNMP. Variveis ligadas

associam instncias particulares de objetos com seus valores correntes.

2.7 FORMATO DAS MENSAGENS SNMP

As informaes so trocadas entre a estao gerenciadora e o agente na forma de

mensagens SNMP. Cada mensagem inclui o nmero da verso do SNMP, um nome de

comunidade e um dos cinco tipos de unidades de dado do protocolo como mostrado naFigura 2.7.1. A Tabela 4 explica o significado de cada campo do cabealho de

mensagens.

Figura 2.7.1 Formato de mensagens SNMP


41/86

40

Campo Descrio

Version Verso do SNMP, a verso 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 exceo no

processamento da solicitao.

Error-index Quando oError-status no zero (ou seja, ocorreu algum erro)

este campo fornece informaes a mais como ndice da

varivel que causou a exceo. Uma varivel uma instncia

de um objeto gerenciado.

Variable

bindings

Lista de nomes de variveis e valores correspondentes. Em

alguns casos como na mensagem de GetRequest, esses valores

so nulos.

Enterprise Tipo de objeto que gerou a trap.

Agent-addr Endereo do agente (onde est o objeto) que gerou a trap.

Generic-trap Tipo de trap genrica. Informa os tipos de valores padres

definidos para traps, ou valorSpecific.

Specific-trap Cdigo de trap especifica, no caso do valor do campogeneric-

trap ser Specific.

Time-stamp Contm o valor do objetosysUpTime, ou seja, o tempo desdeA ltima reinicializao da entidade de rede da gerao da trap

As mensagens de GetRequestso utilizadas para obter instncias de objetos que so

identificados no campo variable bindings da PDU. O agente responde este tipo de

mensagem com GetResponse, contento no campo request-id o mesmo nmero do pacote

de recebimento, e no campo variable bindings so colocados os valores das instncias

Tabela 4 Formato das mensagens utilizadas no SNMP


42/86

41

solicitadas. As operaes de GetRequestso atmicas, ou todos os objetos solicitados so

recuperados ou retornado um erro com o cdigo devido.

As mensagens de GetNextRequest so praticamente iguais as de GetRequest. A

diferena que para o GetRequestso retornados os valores das instncias solicitadas, j

no GetNextRequest so retornados os valores das prximas instncias quelas solicitadas,

seguindo a ordem lexicogrfica dos OIDs (Object Identifier). E ainda, da mesma forma que

o GetRequest, a operao GetNextRequest atmica, informando um erro se algum dos

objetos solicitados no puder ser recuperado.

Ainda seguindo o mesmo padro das mensagens GetRequest, as mensagens

SetRequest contm os nomes das instncias dos objetos que tero os valores de suas

instncias alterados e os novos valores para cada uma das instncias. O agente tambmresponde essa mensagem com um GetResponse contendo o mesmo request-id do pacote

recebido, e a operao de set tambm atmica, se alguma das instncias no puder ser

atualizada, seja por erro na sua identificao, seja pelo envio de um valor incorreto, ser

informado um erro e a operao no ser concluda com sucesso.

Ao contrrio das outras mensagens, as mensagens de Trap no necessitam de

nenhuma resposta por parte da estao gerenciadora, e so enviadas assim que algum

evento de relevncia tenha ocorrido na estao gerenciada. As informaes enviadas poruma Trap so muitas vezes especficas da implementao, sendo que os valores enviados

no campo variable bindings so estritamente dependentes da implementao.

2.8 PROXIES

O uso do SNMP exige que todos os agentes, bem como as estaes 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, queno suportem qualquer parte da sute de protocolos do TCP/IP. Ainda, existem numerosos

sistemas, como certos computadores pessoais que implementam o TCP/IP para suas

aplicaes, mas que no desejam acrescentar o peso do SNMP, lgica do agente e dados da

MIB em seu sistema.

De modo a permitir a gerncia de sistemas que no suportam a implementao do

SNMP, foi desenvolvido o conceito de proxy. Neste esquema, o agente SNMP funciona

como umproxy para um ou mais equipamentos. Veja a Figura 2.8.1.


43/86

42

Neste caso, a estao de gerenciamento manda requisies para o equipamento

onde est o agente proxy. O proxy converte a requisio para o protocolo de

gerenciamento que utilizado pelo equipamento, podendo utilizar comunicao atravs do

canal serial, paralelo ou mesmo utilizando Ethernet. Assim que a resposta recebida pelo

agente (proxy), ele converte a resposta em uma resposta padro do SNMP e repassa para aestao 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 no tenha a capacidade de informar o proxy na

ocorrncia de algum evento, o proxy pode ter, adicionado a sua lgica, algum

processamento depooling, de modo a ficar a par de qualquer modificao no estado do

equipamento gerenciado.

2.9 AS VANTAGENS DO SNMPA vantagem maior sua popularidade. Agentes SNMP, pois como j foi dito, esto

disponveis para dispositivos de rede que variam de computadores, pontes, modems, at

impressoras. O fato que o SNMP existe com tal apoio d crena considervel razo para

sua existncia. O SNMP se tornou interopervel.

O protocolo s pode ser utilizado em uma variedade de dispositivos porque

simples e concentra a maior parte do processamento na mquina do gerenciador,

permitindo que os ns da rede utilizem o protocolo mesmo no tendo grande poder de

Figura 2.8.1 Gerenciamento utilizando o conceito de proxy


44/86

43

processamento.

O projeto de sistemas que envolvam estudos em SNMP mais simples se

comparado com outros protocolos de gerenciamento de redes. Conseqentemente de

mais fcil implementao em redes grandes, j que no necessita de muito tempo para

configurao e no exige muito processamento dos ns da rede. Tambm, seu projeto

simples torna factvel (embora no imediato) para um usurio programar variveis que ele

gostaria de monitorar, pois cada varivel contm apenas as seguintes informaes:

O nome da varivel;

Os tipos de dados da varivel (inteiro, string, etc.);

Se a varivel somente de leitura ou de leitura e escrita;

O valor da varivel;O resultado lquido desta simplicidade um gerente de rede que fcil de

implementar e que tambm no impe muito overhead em uma rede existente.

Expansibilidade outro benefcio do SNMP. Por causa de seu projeto simples, ele

pode ser atualizado de forma a adequar-se s necessidades dos usurios futuros. E como os

agentes SNMP podem ser estendidos para cobrir dados de dispositivos especficos.

Outro ponto importante, que com a implementao do protocolo SNMP,

componentes de redes, locais ou no, podem ser monitorados e gerenciados, em princpio,igualmente.

2.10 AS DESVANTAGENS DO SNMP

O SNMP no de maneira nenhuma um protocolo de gerncia de rede perfeito, e

assim possui falhas. Contudo, por causa de seu projeto flexvel, a maioria destas

deficincias pode ser contornada.

A primeira deficincia do protocolo SNMP que ele tem grandes falhas de

segurana, que podem dar acesso a invasores, que capturam informaes na rede, aotransitar por ela.

Estes invasores tambm podem desligar alguns terminais. A soluo para este

problema surgiu com a expansibilidade do SNMP, verificada na verso SNMPv2, que

somou alguns mecanismos de segurana que ajudaram a combater os trs principais

problemas de segurana: privacidade de dados (prevenir os invasores de ganhar acesso

informao levada pela rede), autenticao (impedir os invasores de enviar falsos dados

pela rede), e controle de acesso (que restringe o acesso de variveis particulares a certos


45/86

44

usurios, removendo assim a possibilidade de um usurio derrubar a rede acidentalmente).

Na verdade, o SNMP prov pouco suporte para esquemas de autenticao. Ele

suporta apenas um esquema com duas passwords. Uma password pblica permite ao

gerenciador pedir o valor de variveis (get), e outra password privada permite ao

gerenciador fixar valores de variveis (set). Essas passwords so chamadas communities, e

todo dispositivo conectado numa rede gerenciada por SNMP devem ter essas duas

communities configuradas. Sempre verificada a presena de uma das communities em

cada mensagem do gerenciador para o agente, mas descrita sem nenhuma proteo, como

texto simples, propiciando falhas de segurana. No difcil um invasor descobrir as

passwords e influenciar no funcionamento da rede.

Outros problemas podem ser citados: o protocolo no muito eficiente, pois h atransmisso de muitos dados desnecessrios; a organizao das variveis na rvore MIB

tambm no muito eficiente. Alm disso, por usar endereamento IP, se h um problema

de roteamento na rede e se um dispositivo no poder ser alcanado, impossvel monitor-

lo ou reconfigur-lo.

2.11 MTODOS DE IMPLEMENTAO

Como implementar o protocolo SNMP uma questo encontrada por muitos

administradores de rede atualmente. O primeiro passo implementar a comunicao porTCP/IP, geralmente dando a cada n da rede um endereo IP diferente. O passo seguinte

adquirir (ou programar) softwares para o agente e o gerente, onde ambos geralmente j

devem vir com interface grfica para facilitar a configurao e a visualizao dos dados.

Os agentes devem ser instalados em cada n da rede, enquanto o gerente deve ser

instalado em mquinas das quais se deseja monitorar a rede. Da geralmente s seguir as

instrues dos programas para configurar a rede SNMP, especificando as MIBs.

2.12 CONSTRUO DE AGENTES SNMPOs Agentes SNMP so daemons UDP que esperam requisies na porta 161 e

enviam traps na porta 160;

Esse agente interage com o sistema de gerenciamento via SNMP, mas nenhuma

especificao existe na interao com o recurso gerenciado;

Qualquer protocolo ou mtodo pode ser empregado: sockets, RPC, memria

compartilhada ou arquivos.

Para a construo do agente, deve-se escolher qual ser o tipo de agente: extensvel


46/86

45

ou estendido. Se ele for extensvel, normalmente j implementa a MIB-II e usam o SNMP

diretamente. Possuem APIs (Aplication Programming Interface) de programao para

outros agentes.

Se ele for estendido, poder implementar normalmente complementos da MIB II

(objetos especficos) e usar o SNMP indiretamente de outro agente. Interagem com um

agente atravs de APIs de programao.

O agente extensvel deve implementar o SNMP, para que os agentes estendidos

utilizem;

Um problema j resolvido diretamente em um agente estendido: o protocoloSNMP;

A interao com os recursos ainda deve ser feita de forma proprietria;

Um agente extensvel pode possuir vrios agentes estendidos, interagindo com

recursos diferentes.

Normalmente um agente extensvel fornecido pelo sistema operacional

(Windows) ou por bibliotecas especficas (Unix). Alm do agente, tm-se tambm

bibliotecas auxiliares para manipulao de estruturas do protocolo (SNMPAPI).Existem basicamente trs tcnicas especiais de construo de agentes: construo

direta via sockets, proxy SNMP para extenso direta do agente e construo de agentes

estendidos via API dos agentes extensveis.

2.12.1 TCNICAS DE CONSTRUO USANDO SOCKETS

Neste tipo de tcnica, aloca-se a porta UDP 161 e as mensagens so recebidas

remotamente.

Figura 2.12.1 Uso dos agentes extensivos/estendidos


47/86

46

A aplicao deve ser capaz de entender as mensagens que chegar, isto , deve

implementar o protocolo SNMP. Depois das requisies, as respostas devem ser geradas

tambm de acordo com o protocolo. A aplicao deve saber enviar traps diretamente a

porta 160 remota do gerente associado. Normalmente, deve-se implementar a MIB II, alm

dos objetos de gerenciamento extras.

2.12.2 TNICAS DE CONSTRUO USANDO PROXY

Sobrepe-se o agente local atravs de um novo agente, que ir implementar objetos

extras, e chamar o agente original para os objetos anteriores. Isto evita a implementao

da MIB II.

Essa implementao possui dois problemas: duas portas so usadas para se acessar

alguns recursos. Cascateamento de proxies e duplo mapeamento em plataformas de uma

mesma mquina.2.12.3 TCNICAS DE CONSTRUO USANDO AGENTE ESTENDIDO

Apenas uma porta usa SNMP no sistema: 161 do agente extensvel. Os agentes

estendidos so chamados apenas quando necessrio. Vrios agentes estendidos associados

a um mesmo agente extensvel.

Figura 2.12.2 Uso dos sockets

Fi ura 2.12.3 Uso do a ente estendido


48/86

47

CAPTULO 3

RMON (REMOTE MONITORING)

No captulo 3, trata-se do protocolo RMON e cita-se as suas potencialidades.

Tambm se mostra como vantajoso trabalhar com mltiplos gerentes. So

citados os tipos bsicos do protocolo RMON: RMON1 e RMON2 e a forma

como eles operam. Faz-se a meno de equipamentos que implementam

servios com esse protocolo de gerenciamento.


49/86

48

O protocolo SNMP no adequado para ambientes de redes corporativas

constitudas de diversas redes locais conectadas atravs de longa distncia. Esses enlaces

de rede de longa distncia, por operarem a taxas de transmisso inferiores s LANs que as

interconectam, passam a ter grande parte da sua banda de transmisso ocupada para

informaes de gerenciamento. Uma soluo encontrada para dirimir este problema foi o

RemoteMONitoring(RMON).

O protocolo RMON oferece suporte implementao de um sistema de

gerenciamento distribudo. Nele, fica atribuda aos diferentes elementos, tais como

estaes de trabalho, hubs, switches ou roteadores, das redes locais remotas a funo de

monitor remoto. Cada elemento RMON tem, ento, como tarefas, coletar, analisar, tratar e

filtrar informaes de gerenciamento da rede e apenas notificar estao gerente oseventos significativos e situaes de erro. No caso de existirem mltiplos gerentes, cada

elemento RMON deve determinar quais informaes de gerenciamento devem ser

encaminhados para cada gerente.

Sendo assim, os objetivos do protocolo RMON so:

Reduzir a quantidade de informaes trocadas entre a rede local gerenciada

e a estao gerente conectada a uma rede local remota;

Possibilitar o gerenciamento contnuo de segmentos de redes locais, mesmoquando a comunicao entre o elemento RMON e a estao gerente estiver

temporariamente interrompida;

Permitir o gerenciamento pr-ativo da rede, diagnosticando e registrando

eventos que possibilitem detectar o mau funcionamento e prever falhas que interrompam

sua operao;

Detectar, registrar e informar estao gerente: condies de erro e eventos

significativos da rede; Enviar informaes de gerenciamento para mltiplas estaes gerentes,

permitindo, no caso de situaes crticas de operao da rede gerenciada, que a causa da

falha ou mal funcionamento da rede possa ser diagnosticada a partir de mais de uma

estao gerente.


50/86

49

3.1 OBJETIVOS DO PROTOCOLO RMON

Os dispositivos de monitoramento remoto de rede (dispositivos RMON) so

instrumentos que existem com o propsito de gerenciar uma rede. Muitas vezes estes

dispositivos so dedicados e devotam significativos recursos internos para o propsito de

gerenciamento de rede.

Uma organizao pode dispor de diversos destes dispositivos, um por segmento de

rede, para gerenciar sua rede Internet.

A especificao RMON uma definio de uma MIB. O objetivo, contudo,

definir padres de monitorao e interfaces para a comunicao entre agentes/gerentes

SNMP.

Os objetivos da implementao de um dispositivo RMON, so os que se seguem: Operao Off-Line - esta a condio em que a estao gerenciadora no

est em contato constante com o dispositivo RMON. Presta-se para desenhar redes de

baixo custo de comunicao (redes por acesso discado ou conexes com Wide Area

Networks - WAN) ou para acidentes onde as falhas na rede afetam a comunicao entre a

estao gerenciadora e os dispositivos RMON. Desta forma, o monitor configurado para

coletar estatsticas e fazer diagnsticos continuamente, mesmo se a conexo com o gerente

no for possvel ou apresentar falhas. O monitor pode tambm notificar a estao degerenciamento se eventos excepcionais ocorrerem;

Monitoramento Preemptivo - se o monitor tiver recursos disponveis, estes

podem ser usados para executar diagnsticos continuamente e para analisar a performance

da rede. Quando uma falha ocorrer, o monitor pode notificar a estao de gerenciamento e

armazenar o histrico estatstico referente falha. Posteriormente este histrico pode ser

enviado a estao de gerenciamento com o objetivo de se fazer um estudo mais profundo e

permitir a deteco e reparo da falha; Deteco de Problemas e Gerao de Relatrios - o monitor pode ser

configurado para reconhecer certas situaes, mais notadamente condies de erro e checar

continuamente por elas. Quando uma destas situaes ocorrer, o monitor pode registr-la e

report-la a estao de gerenciamento;

Anlise 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 anlise significativa dos dados que coletam.


51/86

50

Por exemplo, estes dispositivos podem determinar qual host gera maior trfego ou mais

erros na rede;

Mltiplos Gerentes - uma configurao de rede pode ter mais de uma

estao gerente para dar mais confiabilidade, executar funes diferentes e prover

capacidades de gerncia para unidades diferentes dentro da organizao.

3.1.1 CONTROLE DE MONITORES REMOTOS

Um monitor remoto (dispositivo RMON) pode ser configurado como uma funo

disponvel em um sistema ou como um dispositivo dedicado. Configurado como

dispositivo dedicado, o monitor capaz de efetuar operaes mais complexas.

A definio da MIB RMON contm caractersticas que suportam controle extensivoda estao de gerenciamento. Estas caractersticas dividem-se em duas categorias:

Configurao

Tipicamente, um monitor remoto necessitar ser configurado para coletar dados. A

configurao 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 contm parmetros que descrevem o dado na tabela de

dados, que somente para leitura. Assim, a estao gerente envia os parmetrosapropriados para configurar o monitor remoto para coletar os dados desejados. Os

parmetros so configurados pela adio de um novo registro na tabela ou alterando uma

existente. Desse modo, funes para serem executadas pelo monitor so 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 parmetro na tabela de controle necessrio primeiro

invalidar a entrada. Isto causa a retirada daquela entrada e de todos os registros associadosem tabelas de dados. A estao gerente pode ento criar um novo registro de controle com

os parmetros modificados. O mesmo mecanismo usado para apenas desabilitar uma

coleo de dados. Quando um registro da tabela de controle apagado, os registros das

tabelas de dados associadas so apagados, e os recursos usados pelos registros so

recuperados.


52/86

51

Invocao de Ao

O SNMP pro

protocolo de gerenciamento

Documents

Transcript of protocolo de gerenciamento