P. 1
protocolo de gerenciamento

protocolo de gerenciamento

|Views: 1,940|Likes:
Published by Luis Soto

More info:

Published by: Luis Soto on Feb 28, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/16/2013

pdf

text

original

Sections

  • 1.1.2 GERENCIAMENTO DE CONTABILIDADE
  • 1.1.3 GERENCIAMENTO DE CONFIGURAÇÃO
  • 1.1.4 GERENCIAMENTO DE DESEMPENHO
  • 1.1.5 GERENCIAMENTO DE SEGURANÇA
  • 1.2 AXIOMAS DE GERENCIAMENTO DE REDES
  • Figura 1.2.1 - Sistema de gerenciamento SNMP
  • 2.1 HISTÓRICO DA GERÊNCIA DE REDES TCP/IP
  • 2.2 DESENVOLVIMENTO DO SNMP
  • Tabela 1 - RFCs relacionadas ao gerenciamento de redes no TCP/IP
  • Tabela 2 - RFCs relacionadas ao SNMPv2c
  • Tabela 3 – RFCs relacionadas ao SNMPv3
  • 2.3 ARQUITETURAS DE GERENCIAMENTO
  • Figura 2.3.1 - Possível configuração de sistema com SNMP
  • 2.4 O MODELO DE GERENCIAMENTO DA INTERNET
  • 2.5 DEFINIÇÃO DOS RELACIONAMENTOS ADMINISTRATIVOS
  • 2.7 FORMATO DAS MENSAGENS SNMP
  • Tabela 4 – Formato das mensagens utilizadas no SNMP
  • 2.9 AS VANTAGENS DO SNMP
  • Figura 2.8.1 – Gerenciamento utilizando o conceito de proxy
  • 2.11 MÉTODOS DE IMPLEMENTAÇÃO
  • 2.12 CONSTRUÇÃO DE AGENTES SNMP
  • 2.12.1 TÉCNICAS DE CONSTRUÇÃO USANDO SOCKETS
  • Figura 2.12.1 – Uso dos agentes extensivos/estendidos
  • 2.12.2 TÉNICAS DE CONSTRUÇÃO USANDO PROXY
  • 2.12.3 TÉCNICAS DE CONSTRUÇÃO USANDO AGENTE ESTENDIDO
  • Figura 2.12.2 – Uso dos sockets
  • 3.1 – OBJETIVOS DO PROTOCOLO RMON
  • 3.1.1 CONTROLE DE MONITORES REMOTOS
  • 3.3 - Remote Monitoring Management Information Base (RMON-MIB)
  • 3.3.1 - Grupos da RMON1-MIB
  • 3.3.2 - Grupos da RMON2-MIB
  • 3.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON
  • 4.1 ESTRUTURA DA MIB
  • 4.3 DEFINIÇÕES PARA SMI
  • 5.2 - ARQUITETURA DE UM CLP
  • 5.3 PROPOSTA DE MIB
  • 5.5.2 AGENTE COMO UM PROXY
  • Figura 5.6.1 – Módulos usados para interfacear com o CLP
  • 6.1 O PAPEL DOS SOFTWARES DE GERENCIAMENTO
  • 6.2 PLATAFORMAS DE GERENCIAMENTO
  • 6.4 – MRTG (MULTI ROUTER TRAFFIC GRAPHER)
  • Figura 6.4.1 – Gráfico gerado pelo MRTG
  • Figura 6.5.3 – Guia Monitor
  • Figura 6.5.4 – Guia Services

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

3 ARQUITETURAS DE GERENCIAMENTO--------------------------------------------30 2.3 1.1.6 OPERAÇÕES SNMP------------------------------------------------------------------------37 2.11 2.10 2.4 1.1.1.2 1.2 DESENVOLVIMENTO DO SNMP------------------------------------------------------25 2.5 TIPOS DE GERENCIAMENTO--------------------------------------------------------------14 GERENCIAMENTO DE FALHAS-----------------------------------------------------------14 GERENCIAMENTO DE CONTABILIDADE----------------------------------------------15 GERENCIAMENTO DE CONFIGURAÇÃO-----------------------------------------------15 GERENCIAMENTO DE DESEMPENHO--------------------------------------------------16 GERENCIAMENTO DE SEGURANÇA---------------------------------------------------16 1.1 TÉCNICAS DE CONSTRUÇÃO USANDO SOCKETS--------------------45 2.12.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.2 TÉCNICAS DE CONSTRUÇÃO USANDO PROXY-----------------------46 2.5 DEFINIÇÃO DOS RELACIONAMENTOS ADMINISTRATIVOS----------------35 2.1 1.3 TÉCNICAS DE CONSTRUÇÃO USANDO AGENTE ESTENDIDO---46 .2 AXIOMAS DE GERENCIAMENTO DE REDES---------------------------------------------17 CAPÍTULO 2–SNMP (SIMPLE NETWORK MANAGEMENT PROTOCOL)-----------20 2.12.1.1 1.1 HISTÓRICO DA GERÊNCIA DE REDES TCP/IP--------------------------------------21 2.4 O MODELO DE GERENCIAMENTO DA INTERNET-------------------------------33 2.9 AS VANTAGENS DO SNMP-------------------------------------------------------------42 2.12.1.12 AS DESVANTAGENS DO SNMP-----------------------------------------------43 MÉTODOS DE IMPLEMENTAÇÃO----------------------------------------------44 CONSTRUÇÃO DE AGENTES SNMP-------------------------------------------44 2.8 PROXIES-------------------------------------------------------------------------------------41 2.7 FORMATO DAS MENSAGENS SNMP-------------------------------------------------39 2.

3 O PROJETO FREENMS------------------------------------------------------------------73 6.1.2 RMON1 E RMON2-------------------------------------------------------------------------52 3.3.3 PROPOSTA DE MIB----------------------------------------------------------------------66 5.3 DEFINIÇÕES PARA SMI-----------------------------------------------------------------62 CAPÍTULO 5 – ESTUDO DE CASO-------------------------------------------------------------65 5.VI CAPÍTULO 3 – RMON (REMOTE MONITORING)----------------------------------------47 3.2 PLATAFORMAS DE GERENCIAMENTO--------------------------------------------72 6.4 TRAPS---------------------------------------------------------------------------------------67 5.3 REMOTE MONITORING INFORMATION BASE (RMON-MIB)----------------53 3.1 ESTRUTURA DA MIB--------------------------------------------------------------------58 4.1.5 WHATSUP----------------------------------------------------------------------------------77 CONCLUSÃO--------------------------------------------------------------------------------------------84 REFERÊNCIAS BIBLIOGRÁFICAS----------------------------------------------------------------75 .1 CONTROLE DE MONITORES REMOTOS-------------------------------------50 3.5 ALTERNATIVAS DE IMPLEMENTAÇÃO DO AGENTE-----------------------67 5.3.1 3.1 O PAPEL DOS SOFTWARES DE GERENCIMENTO-------------------------------72 6.2 DEFINIÇÃO DE OBJETOS---------------------------------------------------------------62 4.1 OBJETIVOS DO PROTOCOLO RMON--------------------------------------------------49 3.4 MRTG (MULTI ROUTER TRAFFIC GRAPHER)------------------------------------75 6. 2 MÚLTIPLOS GERENTES---------------------------------------------------------51 3.1 5.2 AGENTE NO PRÓPRIO CLP-------------------------------------------------67 AGENTE COMO UM PROXY-----------------------------------------------68 5.5.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON----------------------------------55 CAPÍTULO 4 – MANAGEMENT INFORMATION BASE (MIB)------------------------56 4.5.6 IMPLEMENTAÇÃO DO SOFTWARE AGENTE----------------------------------69 5.1 APLICAÇÃO COM CLP------------------------------------------------------------------66 5.2 ARQUITETURA DE UM CLP-----------------------------------------------------------66 5.2 GRUPOS DA RMON1-MIB-----------------------------------------------------53 GRUPOS DA RMON2-MIB-----------------------------------------------------54 3.7 OBSERVAÇÕES LEVANTADAS------------------------------------------------------70 CAPÍTULO 6 – SOFTWARES DE GERENCIAMENTO-----------------------------------------71 6.

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

5.2.3 Figura 6.1 Figura 6.5.12.8.1.7.1 Figura 2.5.3 Figura 5.1 Uso de agentes extensivos/estendidos-----------------------------------------------45 Figura 2.1 Figura 6.5.1 Figura 5.5.2 Uso dos sockets-------------------------------------------------------------------------46 Figura 2.1 Formato das mensagens SNMP------------------------------------------------------39 Figura 2.3 Uso do agente estendido---------------------------------------------------------------46 Figura 4.1 Sistema de gerenciamento SNMP----------------------------------------------------19 Arquitetura do protocolo SNMPv3--------------------------------------------------29 Possível configuração de sistema com SNMP-------------------------------------32 Figura 2.VIII Lista de Figuras Figura 1.4.1 Figura 6.5.6 Figura 6.1 Figura 5.5.7 Árvore da MIB construída pelo MIB Browser------------------------------------58 Agente implementado no controlador----------------------------------------------67 Implementação usando a pilha TCP/IP---------------------------------------------67 Implementação com agente do tipo proxy-----------------------------------------68 Módulos usados para interfacear com o CLP-------------------------------------69 Gráfico gerado pelo MRTG---------------------------------------------------------76 Guia Geral-----------------------------------------------------------------------------78 Guia SNMP----------------------------------------------------------------------------78 Guia Monitor--------------------------------------------------------------------------79 Guia Services--------------------------------------------------------------------------80 Guia Alerts----------------------------------------------------------------------------80 Guia Notes-----------------------------------------------------------------------------81 Guia Menu-----------------------------------------------------------------------------82 .4 Figura 6.3.2 Figura 5.5.12.5.2 Figura 6.6.2.1 Gerenciamento utilizando o conceito de proxy------------------------------------42 Figura 2.5.1 Figura 2.5 Figura 6.12.

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 .

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. Além disso. desenvolvimento e utilização de protocolos de gerência. este trabalho apresenta um estudo sobre a origem. sobretudo na qualidade de serviço. produtividade. foi necessário ampliar as ferramentas de supervisão de rede. em específico: SNMP e RMON. 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ógicoprogramável (CLP). segurança e portabilidade nas operações. Sendo assim. discutimos alguns aplicativos que utilizam estes protocolos.X RESUMO Com o objetivo de garantir a qualidade do serviço de redes para os diversos tipos de usuários. favorecendo a agilidade. .

Essas ferramentas se baseiam na arquitetura gerente/agente. mais tarde amplamente adotado como padrão de gerência em redes TCP/IP (Transmission Control Protocol /Internet Protocol). fazer alguma operação remotamente. geralmente. ferramentas de gerência padrões se tornaram necessárias. visto que a rede crescia continuamente. Este ciclo de gerência pode ser resumido em observação (recuperar valores e eventos) e controle (gerar eventos e alterar valores). quando alguma atividade de gerência era necessária. são fundamentais as ferramentas computacionais que auxiliem na gerência e administração das redes. até que a RFC 1157. base de gerência MIB-II (Management Information Base II) e o protocolo RMON (Remote Network Monitoring) e a elaboração do texto. não se aplicando num contexto geral. Para essas organizações. onde o gerente envia requisições ao agente.INTRODUÇÃO As redes de computadores e sistemas distribuídos estão se tornando cada vez mais importantes dentro das organizações comerciais. a partir da estação gerente. propôs o protocolo SNMP (Simple Network Management Protocol). Até aquele momento. 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). . sendo. que atua diretamente nos recursos gerenciados. E ter que ir pessoalmente aos equipamentos era inviável. especificamente o SNMP e o RMON. Este trabalho de projeto final tem como objetivo propor um estudo dos protocolos de Gerência de Redes. que demandam grandes esforços dos gerentes e administradores de rede. embora problemas ocorram seguidamente. Mas as ferramentas proprietárias eram úteis somente para um certo equipamento de certos fabricantes. com a interconexão de equipamentos heterogêneos cada vez mais comuns. governamentais e institucionais. As interfaces pelas quais o administrador realizará essas ações. Então algumas RFCs (Request For Comment) foram propostas ao IAB (Internet Architecture Board) sem muito êxito. orientadas a texto ou gráficos bidimensionais. o gerente deveria ir até o equipamento relevante e realizar algum tipo de teste diretamente nele. A detecção dos problemas e a administração de todos os recursos são tarefas complexas. ou através de ferramentas proprietárias. os recursos disponibilizados pela rede e suas aplicações suportadas são indispensáveis. de 1990. são de extrema importância. Quando a rede ARPANET se tornou a rede mundial. Desta forma.

como se estivesse local a eles. quase representando imagens fotográficas dos equipamentos. Foi feita ainda. roteadores) auxiliava na identificação rápida dos equipamentos. o uso de ícones que representavam os diversos equipamentos (ícones para estações. Utilizou-se para este trabalho uma metodologia que consiste na identificação do contexto. utilizando os protocolos SNMP e RMON. uma pesquisa sobre a manipulação dos objetos gerenciáveis. O objetivo desta pesquisa é fazer um estudo sobre a gerência de rede. a tarefa de gerência de rede se baseia em duas ações típicas: observação e controle à distância. a exigência por efetivamente visualizar. e para o RMON.12 Não tendo muitas ambições. tem o aplicativo pelo qual o operador humano usará o protocolo. Assim como as tarefas foram se tornando complexas. alguns objetivos intermediários são: Estudo do estado da arte em gerência de rede. para permitir a interação entre eles na rede. O dispositivo que contém o gerente. O software gerente envia comandos de leitura ou armazenamento ao agente. que tem como única operação dar a devida resposta ao requisitante. As interfaces foram se tornando gráficas. contemplando o interfaceamento mais realístico do operador humano com equipamentos remotos. a interface do gerente é decisiva e importante. para hubs. memória e interface. gerente/agente. Estudo do protocolo SNMP e das MIB II. baseado na arquitetura cliente/servidor. Logo imagens mais realísticas passaram a serem usadas. o protocolo deveria ser simples e suportar operações simples. Desta maneira. localizado numa máquina que ofereça um certo poder de processamento. estudando as tecnologias envolvidas para o SNMP. e RMON e MIBs. Segundo esse paradigma. com ênfase às ações manifestadas em operações do protocolo SNMP e RMON. . para as MIBS. Desta forma. ou especificamente. monitorar e manipular os recursos gerenciados se torna essencial.

tais como o Gerente e o Agente. os componentes básicos de um sistema que utiliza o SNMP. . estudando as suas subclasses. São definidos. tem-se uma abordagem acerca da teoria que abrange a gerência de redes. tendo os passos básicos para operar eficazmente no processo. Serão discutidos os axiomas da gerência de redes.13 CAPÍTULO 1 TEORIA SOBRE GERENCIAMENTO DE REDES No capítulo 1. também.

isto é. Duas causas principais têm tornado árduo o trabalho de isolamento e teste de problemas: Diversidade dos níveis do pessoal envolvido: técnicos. cada fornecedor oferecendo ferramentas próprias de controle e monitoração.1. O ideal é que as falhas sejam detectadas antes que os efeitos prejudiciais. Opcionalmente. 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. algumas funções servem de suporte para as funções das outras áreas. dar manutenção a cada um dos objetos gerenciados. Pode-se conseguir este ideal através do . Por outro lado. Gerenciamento de performance e Gerenciamento de contabilização.1 TIPOS DE GERENCIAMENTO 1.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. Gerenciamento de segurança. pode-se gerar um registro das ocorrências na rede. decorrentes destas. possam vir a acontecer. mas até mesmo em várias áreas de gerenciamento. e quais não estão funcionado. Muitas vezes as áreas funcionais possuem funções de gerenciamento que se sobrepõem. Diversidade nas formas de controle e monitoração: produtos cada vez mais complexos. e tomar decisões para restabelecer as unidades do sistema que venham a dar problemas. 1. 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 expandir melhor os meios de pesquisa e atuação na área de gerência. para indicar quais elementos estão funcionando. gerentes e engenheiros. Gerenciamento de configuração.1 GERENCIAMENTO DE FALHAS A gerência de falhas tem a responsabilidade de monitorar os estados dos recursos. quais estão em mau funcionamento. são utilizadas não somente uma. apesar de terem finalidades em cada uma. a ISO dividiu o gerenciamento de redes em cinco áreas funcionais: Gerenciamento de falhas.

incluindo a verificação da existência dos componentes e a verificação de interconectividade entre estes componentes.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. No mundo de hoje. 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. tendo então.1. A gerência de configuração é correspondente a um conjunto de facilidades que permitem controlar os objetos gerenciados. despesas de telecomunicações para acesso a dados remotos e taxas de envio de e-mail. . 1. Início e encerramento das operações sobre os objetos gerenciados.1. identificá-los. a iniciação. 1. estipulando limites e incorporando informações de tarifas em todo o processo de contabilidade.15 monitoramento das taxas de erros do sistema. contabilidade significa tratar com pessoas usando os reais recursos de rede com despesas de operação real. a operação contínua e a posterior suspensão dos serviços de interconexão entre os sistemas abertos. que pode definir as ações necessárias para corrigir o problema e evitar as situações mais críticas. Exemplos destes custos incluem uso do espaço em disco e dados armazenados. o que deve indicar a necessidade de adições e reajustamentos num futuro próximo. Outras considerações incluem informações dos custos dos usuários e recursos gastos. e da evolução do nível de severidade gerado pelos alarmes (função de relatório alarme).3 GERENCIAMENTO DE CONFIGURAÇÃO O objetivo da gerência de configuração é o de permitir a preparação. a partida. que permitem a emissão das notificações de alarme ao gerente. a função de manutenção e monitoramento da estrutura física e lógica de uma rede. coletar e disponibilizar dados sobre estes objetos para as seguintes funções: Atribuição de valores iniciais aos parâmetros de um sistema aberto.

1. as taxas em que estes recursos são pedidos e as taxas em que os pedidos a um recurso são rejeitados. vazão.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. um valor de alerta. ou seja.1. . através de parâmetros estatísticos como atrasos. define-se um valor máximo aceitável (threshold). deve-se monitorar as taxas de utilização dos recursos. 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. protegendo os objetos contra de acessos indevidos. e um valor em que se remove a situação de alerta. disponibilidade e o número de retransmissões realizadas. 1.16 Alteração da configuração do sistema aberto e Associação de nomes a conjuntos de objetos gerenciados.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. Definem-se três modelos para atender aos requisitos de monitoramento de uso dos recursos dos sistemas: Modelo de Utilização: Provê o monitoramento do uso instantâneo de um recurso. Modelo de Rejeição: Provê o monitoramento da rejeição de um pedido de um serviço e Modelo de Taxa de Pedido de Recursos: Provê o monitoramento dos pedidos do uso de recursos. Para cada tipo de monitoramento. Para atingir estes objetivos.1. Deve-se providenciar um alarme ao gerente da rede sempre que se detectarem eventos relativos à segurança do sistema. preocupa-se com o desempenho corrente de rede.

como forma de componentes funcionais úteis à plataforma de gerência o uso de ferramentas gráficas. . o NetView da IBM e o TNG Unicenter. Analisadores de rede. da Computer Associates.17 As informações de gerenciamento de segurança são armazenadas numa MIB especial.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 tráfego devido às informações de gerenciamento não deve aumentar significativamente o tráfego da rede. uma API (Aplication Programming Interface) de programação e segurança no sistema de gerenciamento. Monitores de rede. que se conectam as redes monitorando o tráfego. é necessário observar qual o pacote de softwares que oferece as funcionalidades básicas para gerenciamento de vários dispositivos diferentes. o OpenView da HP. que detectam problemas em termos de cabos e conexões de hardware. A eficiência na realização destas tarefas está diretamente ligada à presença de ferramentas que as automatizem e de pessoal qualificado. que auxiliam no rastreamento e correção de problemas encontrados nas redes. oferecer funcionalidades genéricas para gerenciamento padrão dos vários dispositivos. pode-se citar o NetManager. tendo como objetivo. Como exemplos destas plataformas. Atualmente existem no mercado diversos tipos de ferramentas que auxiliam o administrador nas atividades de gerenciamento. Adicionalmente se pode citar. a qual deve dar apoio as três categorias de atividades de gerenciamento de segurança existentes. 1. da Sun. O agente de protocolo no dispositivo gerenciado. Estas ferramentas podem ser divididas em quatro categorias: Ferramentas de nível físico. não deve aumentar significativamente o resultado de processamento a ponto de prejudicar a função principal daquele dispositivo. Esta MIB é chamada de SMIB (Security Management Information Base). Para se montar uma plataforma de gerenciamento de redes.

Determinar a área funcional de gerenciamento. Isto envolve esforço para identificar. Estes sistemas podem apresentar também uma série de mecanismos que facilitam a identificação. Escolher as aplicações de gerência para os dispositivos. Escolher a plataforma de gerenciamento de acordo com as aplicações selecionadas. notificação e registro de problemas. anormalidades na rede. Como o tempo de espera do usuário pelo restabelecimento do serviço deve ser o menor possível. Geração de gráficos estatísticos em tempo real. Esses são os passos básicos para poder escolher um sistema confiável e que contribua para o gerenciamento de uma rede: Fazer o inventário dos dispositivos gerenciáveis na rede. Evidentemente é preciso montar um banco de dados. através de mensagens ou bips de alerta.18 Sistemas de gerenciamento de redes. tudo isto deve ser feito eficientemente. onde o GERENTE é o próprio sistema de gerenciamento de toda a parte de configuração ligada às aplicações e ao usuário. Geração automática de relatórios contendo as informações coletadas. e o AGENTE é um software que deve ser instalado nos . rastrear e resolver situações de falhas. Apresentação gráfica da topologia das redes. Facilidades para integrar novas funções ao próprio sistema de gerenciamento. 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. contendo informações necessárias para apoiar o diagnóstico e na busca de soluções para problemas da rede. Em redes IP. Os sistemas de gerenciamento de redes apresentam a vantagem de ter um conjunto de ferramentas para análise e depuração da rede. que será gerente da rede. como por exemplo: Alarmes que indicam. os quais permitem a monitoração e controle de uma rede inteira a partir de um ponto central. o sistema de gerenciamento segue o modelo gerente-agente. Dentre a gama de soluções possíveis para o gerenciamento de redes.

2. Apple Machintosh. o qual é como uma linguagem comum utilizada exclusivamente para a troca de informações de gerenciamento. redes Ethernet. Outro aspecto importante é a sua capacidade de gerenciar redes heterogêneas constituídas de diferentes tecnologias.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). Dessa forma. Esta interação é viabilizada pelo protocolo de gerenciamento SNMP. conectando IBM PCs. estações de trabalho SUN e outros tipos de computadores.2. a qual informa sobre algum evento importante ocorrido. veja a Figura 1.1 . Dessa forma. a tarefa do agente é responder as requisições feitas pelo gerente em relação ao equipamento no qual o agente está instalado. As aplicações de gerenciamento utilizam o SNMP para: Fazer polling nos dispositivos de rede e coletar dados estatísticos para análise em tempo real.1. Reconfigurar dispositivos de rede. protocolos e sistemas operacionais. e grande parte do seu sucesso se deve a sua simplicidade. o SNMP pode gerenciar. sendo um protocolo send/receive com apenas quatro operações. . Figura 1. Para melhor compreensão. O conjunto de informações ao qual o gerente pode fazer requisições ou alterações é denominado de Management Information Base (MIB). o gerente consegue conversar com qualquer máquina que fale SNMP. Trocando em miúdos. Token Ring e FDDI. Receber um conjunto limitado de notificações de eventos significativos ou mensagens trap. independente do tipo de hardware e sistema operacional. por exemplo.Sistema de gerenciamento SNMP O protocolo de gerenciamento SNMP constitui atualmente um padrão operacional "de fato".

. discutindo-se sua arquitetura. além das vantagens e desvantagens. A construção de Agentes também será debatida no contexto. formato do quadro de mensagens.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.

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. Finalmente. isso como um resultado do auge da Guerra Fria. uma coleção de LANs (Local Area Networks) e WANs (Wide Area Networks). A origem do TCP/IP foi um projeto. onde um dos aspectos que amedrontavam os setores de defesa era a perda total de comunicações em virtude de um ataque nuclear. de 1969. o DoD reuniu suas pesquisas no Advanced Research Projects Agency (ARPA) que teve como resultado a criação da precursora da Internet. tendo inicialmente apenas poucas dezenas de hosts e logo depois crescendo para centenas de hosts. Este crescimento começou a se intensificar na metade da década de 80. O problema se tornou ainda maior quando a ARPANET se tornou o centro da crescente Internet. a ARPANET. para resolver esses problemas. Um aspecto interessante e inesperado foi o crescimento do TCP/IP em aplicações não militares. foi desenvolvido um conjunto de protocolos padronizados. deram origem aos atuais protocolos da pilha TCP/IP.21 2. além disso. A ARPANET cresceu muito rapidamente. os quais. mas o TCP/IP . precisando de sistemas de suporte à troca de arquivos. do Departamento de Defesa dos Estados Unidos (DoD). De modo a resolver o problema da interoperabilidade. exatamente quando estavam sendo feitos esforços para desenvolver um consenso internacional em torno dos protocolos desenvolvidos pelo OSI. Assim. os protocolos fundamentais dessa pilha TCP/IP nasceram de padrões utilizados em tecnologias militares. Diferentes hosts de diferentes fabricantes deveriam ser conectados. O TCP/IP preencheu as exigências do DoD e se tornou o padrão dessa organização. Estes protocolos foram considerados como padrões oficiais para o Internet Architecture Board (IAB) através de Requests For Comments (RFCs). Tinha como objetivos estudar uma forma de aumentar o compartilhamento de recursos computacionais numa rede e. Afirmava-se que o OSI se tornaria o responsável pela completa interoperabilidade dos sistemas. na década de 70. buscavam uma forma de comunicação mais confiável do que as vulneráveis linhas de cobre do sistema de telefonia. acomodando milhares de terminais e rapidamente ficou claro que um dos principais problemas da ARPANET seria a interoperabilidade. interação entre os terminais e hosts.

ainda mais depois da popularização da Internet. Portanto exige-se mais para conseguir a interoperabilidade de software com o OSI do que com o TCP/IP. com poucas e simples ferramentas. tendo seu desenvolvimento muito lento. o PING pode ter várias funções. Apesar dele apresentar uma funcionalidade muito mais rica que o TCP/IP. que provêem a interoperabilidade dos sistemas e com um alto nível de funcionalidade. caso algum problema ocorresse. incluindo o fato de já ser um conjunto de protocolos maduros. 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. Durante o desenvolvimento do TCP/IP pouco se estava pensando em relação à gerência da rede. 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. de um tamanho ainda bastante reduzido. Um bom exemplo disso é o programa PING (Packet Internet Groper). mas poderosas ferramentas. Inicialmente apenas os desenvolvedores dos protocolos e programadores utilizavam a rede. Outro par de mensagens útil é a time-stamp/time-stamp-reply. O mecanismo dessas mensagens permite que se descubra se é possível a comunicação entre duas entidades da rede. Como exemplos tem- . 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 TCP/IP se tornou tão mais popular no meio comercial por vários motivos. Disponível em qualquer equipamento que suporte IP. isto é conseguido porque quando uma mensagem do tipo echo é recebida.22 cresceu muito nos últimos anos e continuou crescendo a cada dia. vasculhar a rede. Já o OSI demorou demais para apresentar uma versão comercialmente funcional. a entidade é obrigada a retornar o conteúdo da mensagem como uma mensagem do tipo echo-reply. os poucos especialistas que existiam conseguiam. descobrir e corrigir o problema. o qual fornece um mecanismo para verificar as características de atraso na rede. o ICMP permite que se enviem mensagens de controle de roteadores e hosts para um host. Desta forma. nem um protocolo em especial para o gerenciamento da rede. deixando a sua implementação muito difícil e com um grande overhead. Estas mensagens ICMP podem ser utilizadas de forma a criar simples. ele se tornou complexo demais. Durante a década de 70 não foi desenvolvida nenhuma ferramenta. já profundamente testados.

era impossível deixar a cargo de poucos o seu gerenciamento. de entidades a serem gerenciadas e também entidades que têm responsabilidades por gerenciar parte da Internet. de 1987. 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. O ponto de partida do desenvolvimento de ferramentas desse tipo foi o Simple Gateway Monitoring Protocol (SGMP). 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 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. Mas a partir daí. e ainda com ferramentas simples. assim. com um número muito maior de sub-redes. a IAB avaliou estas propostas e aprovou um adicional desenvolvimento do SNMP como uma proposta de mais curto prazo do que o CMOT. Até a década de 80.23 se: determinar se um equipamento de rede pode ser alcançado. com uma rede com proporções cada vez maiores. CMIP over TCP/IP (CMOT): tentativa de incorporar o máximo possível do protocolo (CMIP – Commom Management Information Protocol). podendo desta forma ajudar no isolamento de áreas de congestionamento e pontos de falha. verificar se uma rede pode ser alcançada e verificar as operações entre um servidor e um host. No início de 1988. 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. Com ele três outras abordagens surgiram: 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). O PING pode ser utilizado para verificar a taxa de perda de pacotes em uma sub-rede. Desta forma. serviços e estrutura do banco de dados padronizado pela ISO para o gerenciamento de rede. Simple Network Management Protocol (SNMP): surgiu como um aperfeiçoamento do Simple Gateway Management Protocol (SGMP). o PING e outras ferramentas também simples foram suficientes para se conseguir gerenciar a 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 subredes 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 1155 1157 1212 1213 1643 Data Maio, 1990 Maio, 1990 Março, 1991 Março, 1991 Julho, 1994 Título
Structure and Identification of Management Information

(SMI) for TCP/IP-based Internet
A Simple Network Management Protocol (SNMP)

Concise MIB Definitions Management Information Base for Network Management of TCP/IP-based Internet: MIB-II 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

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; 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; Incorporou os recursos de segurança encontrados no SNMP seguro; 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 MaxRepetitions. 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:

1996 Janeiro. 1996 Janeiro. Tabela 2 . o SNMPv3. De modo a corrigir os problemas de falta de segurança no SNMPv2c. sendo. Essa nova revisão do SNMP utilizou-se do conceito de comunidade. Na necessidade do lançamento dessa nova versão do SNMP optou-se por omitir as características de segurança. 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. Depois de alguns anos de experiência com o SNMPv2 se fez revisão de suas especificações. dando origem as especificações SNMPv2u e SNMPv2*. 1996 Janeiro. 1996 Título Introduction to Community-Based SNMPv2 Structure of Management Information for SNMPv2 Textual Conventions for SNMPv2 Conformance Statements for SNMPv2 Protocol Operations for SNMPv2 Transport Mappings for SNMPv2 Management Information Base for SNMPv2 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. 1996 Janeiro. Em janeiro de 1998 este grupo de trabalho deu origem a uma série de RFCs especificando a nova versão do . deixando apenas algumas modificações. reforçando e aprimorando certas características funcionais e mantendo os prazos determinados. fazendo-se a retirada dos aspectos de segurança do SNMPv2. renomeado para “SNMPv2 baseado em comunidade” ou SNMPv2c. portanto.RFCs relacionadas ao SNMPv2c RFC 1901 1902 1903 1904 1905 1906 1907 1908 Data Janeiro. 1996 Janeiro. 1996 Janeiro. Qualquer ferramenta de administração baseada em SNMP que faça uso desta PDU deve definir seu uso e sua semântica”. dois grupos de trabalhos foram organizados. 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. empregado no SNMPv1.28 “O uso da semântica que precisa da PDU de Report não são definidas. 1996 Janeiro.

Tabela 3 – RFCs relacionadas ao SNMPv3 RFC RFC 2271 RFC 2272 RFC 2273 RFC 2274 RFC 2275 Internet Draft Data Janeiro. 1998 SNMP Janeiro. 1998 SNMPv3 Applications User-Based Security Model for SNMPv3 View-Based Acess Control Model (VACM) for SNMP Introduction to Version 3 of the Internet Network Management Framework O SNMPv3 não substitui o SNMPv1 e o SNMPv2.2. dando preferência ao uso do SNMPv2. 1998 Agosto. O SNMPv3 incorpora características de segurança às funcionalidades já existentes do SNMPv1 e SNMPv2.29 protocolo. A Figura 2. Título Architecture for Describing SNMP Managements Frameworks Message Processing and Dispatching for . O SNMPv3 apenas encapsula as PDUs (Protocol Data Units) do SNMPv1 ou SNMPv2 na sua área de dados e acrescenta um cabeçalho. 1998 Janeiro. 1998 Janeiro. ele apenas apresenta funcionalidades de segurança às duas versões anteriores do protocolo. 1998 Janeiro.1 mostra como se dá o encapsulamento.

MIB (Management Information Base). Além disso. especificando quais partes devem ser implementadas pelos clientes e quais são as responsabilidades dos gerentes.1 . acrescentando-se as características de privacidade. o SNMPv3 consegue contornar o problema que existia nas versões anteriores. bem como propor estratégias de transição mais claras e fáceis. dessa forma. tornando. O protocolo de gerência. mais fácil o avanço das funcionalidades do protocolo sem a necessidade da definição de um novo padrão.30 Figura 2. a estação de gerenciamento serve como a interface entre o sistema de gerenciamento da rede . 2. ou também pode estar implementado em um ambiente distribuído ou hierárquico.3 ARQUITETURAS DE GERENCIAMENTO O modelo de gerência utilizado nas redes TCP/IP inclui os seguintes elementos chaves: Estação de gerenciamento. autenticação e controle de acesso sem que se necessite especificar um protocolo completamente novo. A estação de gerenciamento é normalmente um único equipamento. De qualquer forma. o SNMPv3 definiu uma arquitetura mais modular.2. facilitando a transição dos equipamentos que atualmente já suportam as versões anteriores.Arquitetura do protocolo SNMPv3 Dessa forma. A base de informações de gerenciamento.

Uma interface (gráfica) pela qual o gerente da rede pode monitorar e controlar o estado da rede. deixando o conjunto de aplicações e a interface a cargo de cada fabricante de sistemas de gerenciamentos de rede. Entre o mínimo de funcionalidade que deve ser fornecido pela estação de gerenciamento pode-se citar: Um conjunto de aplicações para análise de dados. Capacidade de traduzir as necessidades do gerente de rede na forma dos atuais meios de monitoração e controle dos elementos remotos da rede. a estação de gerência pode causar a execução de um agente. por exemplo. . e o dado contido nesta variável é obtido. MIBs para pontes. recuperação de falhas. pelo agente. A estação de gerenciamento é ligada ao agente de um protocolo de comunicação.31 (automatizado) e o gerenciamento humano. ou preenchido. ou pode modificar as configurações de um agente através da atribuição de algum valor em um objeto da MIB. mas que são vitais. pontes. existem MIBs para rotedores. etc. Os equipamentos chave. Outro elemento fundamental é o agente de gerenciamento. roteadores. O agente responde por pedidos de informações e ações por parte da estação gerente (ou das estações gerentes) e pode. Da mesma forma. Cada objeto é essencialmente uma variável que representa algum aspecto importante do objeto gerenciado. As definições do SNMP abordam somente os dois itens finais desta lista. Manter e fornecer acesso a um banco de dados de informações extraídas das MIBs de todas as entidades gerenciáveis na rede. como hosts. hubs e outros equipamentos podem ter implementado um agente SNMP que é gerenciado pela estação de gerenciamento. assincronamente fornecer à estação de gerência. A estação de gerência executa o monitoramento da rede através da busca dos valores dos objetos da MIB. entre outras. O protocolo que é utilizado no gerenciamento de redes TCP/IP é o SNMP (Simple Network Management Protocol). pontes. um protocolo de gerência de rede. Estes objetos são padronizados para cada classe particular de equipamentos. 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. Os recursos na rede podem ser gerenciados através de sua representação como objetos. informações que não foram solicitadas.

diminuindo o trabalho dos fabricantes e aumento dessa forma a aceitação do SNMP. o qual está implementado sobre UDP e IP. Ethernet. ele separa a arquitetura de gerenciamento da arquitetura dos equipamentos do hardware.1 . e o faz em três formas.Possível configuração de sistema com SNMP Para uma estação de gerenciamento de protocolos TCP/IP. por exemplo. está localizado no nível de aplicação possível de um ambiente que pode suportar SNMP.25. sendo que o último pode estar implementado sobre qualquer outro protocolo dependente da rede.3. permitindo a coexistência de vários equipamentos de diferentes fabricantes.32 O SNMP foi projetado de modo a ser simples. FDDI (Fiber Data Interface) e X. que nesse caso é o gerente da rede. está localizado no nível de aplicação dessa suíte. ou seja. E finalmente. O processo de gerência obtém informações da rede através do SNMP. que é parte do conjunto de protocolos do TCP/IP. O SNMP. Para uma estação de gerenciamento centralizada. Primeiro. ele é extensível. Na Figura 2. há uma possível configuração que pode ser implementada usando o protocolo SNMP. Cada . 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. Em segundo lugar. Figura 2. os fabricantes podem estender as características funcionais do SNMP.1. reduzindo o custo de desenvolvimento do software agente.3. Ele opera sobre o UDP (User Datagram Protocol).

o SNMP é um protocolo Internet. Existem duas formas de gerenciamento baseada na Web. Objeto gerenciado . e servidores de terminais que estão conectados a rede. A primeira constitui-se em gerentes SNMP usando WebServers e tem como características: O browser acessa um gerente que. acessa as informações via SNMP. como se segue: Elementos de rede . A segunda forma utiliza agentes SNMP com HTTP. UDP e também IP. 2. 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. o gerente pode solicitar informações do agente utilizando mensagens de get. uma lista dos circuitos TCP atualmente ativos em um host particular é um objeto gerenciado. tendo como pontos básicos: O browser acessar diretamente os recursos.também chamados dispositivos gerenciados. Nesse contexto.um objeto gerenciado é qualquer elemento que possa ser gerenciado.4 O MODELO DE GERENCIAMENTO DA INTERNET Como o TCP/IP. 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. por sua vez. roteadores. que são respondidas pelo agente na máquina remota. Agentes . Por exemplo. que é baseada na interação de diversas entidades. As informações são disponibilizadas em páginas HTML pelo gerente SNMP.33 agente deve implementar o SNMP.são módulos de software que residem nos elementos de rede. Ele é uma parte da arquitetura de gerenciamento da Internet. os elementos de rede são dispositivos de hardware como os computadores. Por outro lado. O processo gerente é responsável por interpretar as mensagens SNMP e controlar os valores da MIB do agente.

o Abstract Syntax Notation 1 (ASN. 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.34 O WebServer acessar os dados através de SNMP. Os Network Management Stations (NMS). também chamados consoles.1. uma linguagem usada para descrever os objetos gerenciados da MIB em um formato independente da plataforma. A SMI é definida usando o ASN. Os dados são disponibilizados através de páginas HTML geradas pelo agente SNMP. As definições das regras para descrever as informações de gerenciamento são realizadas pela Structure of Management Information (SMI). O recurso gerenciado deve possuir capacidade de processamento para suportar ao mesmo tempo um WebServer e um agente SNMP. memória substancial e um grande espaço em disco. esta arquitetura é totalmente independente da plataforma dos elementos da rede e dos NMS. para poder absorver mais facilmente novos aspectos das operações de rede e gerenciamento. Sistemas de gerenciamento Internet usam um subconjunto da Open System Interconnection (OSI). são dispositivos que executam aplicações de gerenciamento para monitorar e controlar elementos de rede. Um uso consistente da notação sintática permite que diferentes tipos de computadores compartilhem informações. Além disto. É usada uma notação sintática. O paradigma funcional de controle e monitoração do protocolo foi definido de maneira extensiva. . O SNMP é o protocolo de gerenciamento usado para transportar informações de gerenciamento entre agentes e NMS.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. Fisicamente. Com base nesta arquitetura. monitores coloridos de alta definição. ou seja. o SNMP foi construído para minimizar a quantidade e a complexidade das funções necessárias para gerenciar um agente. os NMS são usualmente workstations com CPU velozes.

e o agente responde através do comando Response. as informações relevantes ao gerenciamento da rede. 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.5 DEFINIÇÃO DOS RELACIONAMENTOS ADMINISTRATIVOS A arquitetura SNMP admite uma variedade de relacionamentos administrativos entre entidades que participam do protocolo. é chamado protocolo de entidades. 2. Em alguns casos é necessário que a troca de informações seja em sentido inverso. Para monitorar os dispositivos gerenciados. o gerente modifica o valor das variáveis armazenadas nos dispositivos gerenciados. através do comando Get. o gerente solicita ao agente uma leitura no valor das variáveis mantidas por estes dispositivos. ainda. determinar que variável um dispositivo gerenciado suporta e colher informações de forma seqüencial. Isto pode ser usado para disparar indiretamente a execução de operações nos recursos associados aos objetos gerenciados. portanto suporta as entidades de aplicação SNMP. O gerente pode. Para isto. para que "possam ser tomadas providências no sentido de contornar os problemas que ocorrem como conseqüência das falhas". isto é. O processo que implementa o SNMP. por sua vez. Para controlar os dispositivos gerenciados. e. processa essas informações com o objetivo de detectar falhas no funcionamento dos elementos da rede. Os agentes coletam junto aos dispositivos gerenciados.35 Os processos que implementam as funções de gerenciamento Internet atuam ou como agentes ou como gerentes. basta que o gerente modifique o parâmetro que indica o tempo até uma reinicialização do sistema. Por exemplo. o agente tem de passar informações para o gerente. das tabelas de variáveis (como as tabelas de roteamento IP) nos dispositivos gerenciados. Um objeto gerenciado representa um recurso e pode ser visto como uma coleção de variáveis cujo valor pode ser lido ou alterado. . ele utiliza as operações transversais (transversal operations). um reboot do elemento de rede pode ser facilmente implementado. O gerente. através do comando Put. Para tanto o gerente envia comandos aos agentes.

36 A junção de um agente SNMP com algum conjunto arbitrário de entidades de aplicação SNMP é chamada de comunidade SNMP. 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. 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. Para toda 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. um subconjunto de objetos na MIB que pertence a este objeto é chamado de visão da MIB SNMP. Para qualquer elemento da rede. Desta forma. Todos os relacionamentos administrativos entre entidades de aplicação SNMP são definidos em termos das políticas de acesso. 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. A junção do modo de acesso SNMP com a visão da MIB é chamada de perfil da comunidade SNMP. 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. Um elemento do conjunto (READ-ONLY. originada por uma entidade de aplicação SNMP que de fato pertence à comunidade SNMP referenciada pela mensagem. um agente proxy provê uma função de conversão de protocolo permitindo a uma estação de gerenciamento aplicar um gerenciamento . READ-WRITE) é chamado de modo de acesso SNMP. é chamada mensagem SNMP autêntica. O agente associado com a política de acesso proxy é chamado de agente proxy. 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 união da comunidade SNMP com o perfil da comunidade é chamada de política de acesso SNMP. Uma mensagem SNMP. O perfil da comunidade SNMP representa um privilégio de acesso específico para variáveis em uma MIB específica. então esta política é chamada política de acesso proxy SNMP. Cada comunidade é nomeada através de uma cadeia de octetos.

Os NMS podem enviar múltiplas requisições sem receber uma única resposta.6 OPERAÇÕES SNMP O SNMP por si só é um protocolo de requisição/resposta simples. Desta forma. Quatro operações são definidas no SNMP.usado pelo agente para informar assincronicamente o NMS sobre algum evento. e outros dispositivos que suportam diferentes estruturas de . Da mesma forma que uma estação gerente pode enviar comandos get e set.permite que o NMS recupere a próxima instância de objetos de uma tabela ou lista em um agente. Essas funções permitem uma forma de acesso muito simples aos dados que são representados pela MIB. ou seja. Se o NMS quiser recuperar todos os elementos de uma tabela de um agente. Ela potencialmente protege os elementos da rede de elaboradas políticas de controle de acesso. as quais incluem as seguintes funções: Get . incluindo dispositivos como modems. GetNext . uma estação gerenciada pode ter um conjunto de gerentes que solicitam e atualizam informações.37 consistente em todos os elementos da rede. multiplexadores. Também não é possível executar comandos para que uma certa ação seja tomada. Assim. não é possível alterar a estrutura da MIB adicionando ou apagando instâncias de objetos. de várias entidades da rede. Além disso. deve se ter um certo controle de como é feito o acesso a MIB. 2. Trap . gerenciamento. não é possível obter todos os objetos de uma tabela em um único comando. ele inicia uma operação Get seguida de uma série de operações GetNext.permite que o NMS modifique valores de uma instância de objetos em um agente. Estas restrições limitam as capacidades do SNMP. através de três aspectos fundamentais: Serviço de autenticação: a estação gerenciada pode limitar o acesso a MIB para apenas certos gerentes que estejam autorizados. a objetos-folha da MIB. Set . como o acesso é feito somente a tipos de dados escalares.permite que o NMS recupere uma instância de objeto do agente. além de receber traps.

Um agente pode estabelecer um número de comunidades para cada aspecto de segurança desejado. como definido na RFC 1157. sendo de sua responsabilidade implementar os serviços de autenticação e controle de acesso. o agente limita o acesso a sua MIB a determinados conjuntos de gerentes. O nome comunitário associa um ambiente de acesso para um conjunto de NMS usando o nome comunitário. Uma comunidade no SNMP é um relacionamento entre um agente SNMP e um conjunto de gerentes que define as características de segurança. O SNMP. Como os dispositivos que não conhecem seu próprio nome comunitário são . Definindo uma comunidade. dois aspectos são envolvidos: diferentes visões da MIB podem ser associadas a cada nome de comunidade. Assim. e ainda. A primeira parte contém a versão e o nome comunitário. Os pacotes de mensagem do SNMP são divididos em duas partes. 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. Esses conceitos são todos relacionados com segurança. implementa uma forma primitiva e limitada baseada no conceito de comunidade. assumindo que. Um NMS dentro de uma comunidade pode ser dito existente dentro de um mesmo domínio administrativo. se o gerente conhece o nome da comunidade.38 Política de acesso: ainda. então ele pode ser considerado confiável. onde cada mensagem SNMP é enviada para o agente contendo o nome da comunidade. com vários nomes de comunidades. podem existir vários agentes utilizando o mesmo nome de comunidade sem que essas comunidades tenham qualquer relação. 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. Cada nome de comunidade tem existência local ao agente. ou seja. Serviço de proxy: uma estação gerenciada pode servir como proxy entre as estações gerente e uma outra estação gerenciada. 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. podem ser dados diferentes níveis de acesso para diferentes estações gerentes. ele pode fornecer diferentes categorias de acesso a MIB para cada estação gerente diferente.

1 – Formato de mensagens SNMP . O PDU do SNMP tem os seguintes campos: Tipo PDU . Variáveis ligadas .7. Variáveis ligadas associam instâncias particulares de objetos com seus valores correntes.7. Cada mensagem inclui o número da versão do SNMP. 2. um nome de comunidade e um dos cinco tipos de unidades de dado do protocolo como mostrado na Figura 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.1.associa as requisições com as respostas. então o administrador de redes usa o nome comunitário como uma forma fraca de autenticação.especifica o tipo que o PDU começará transmitindo.incluir o dado em um PDU SNMP. Identificação de requisição . Figura 2. A Tabela 4 explica o significado de cada campo do cabeçalho de mensagens.39 excluídos das operações do SNMP.

contento no campo request-id o mesmo número do pacote de recebimento. Contém o valor do objeto sysUpTime. esses valores são nulos. é 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. Nome da comunidade de modo a identificar o gerente para o agente Usado para identificar cada mensagem de request. no caso do valor do campo generictrap ser Specific. Endereço do agente (onde está o objeto) que gerou a trap. Utilizado para indicar que ocorreu alguma exceção no processamento da solicitação. ocorreu algum erro) este campo fornece informações a mais como índice da variável que causou a exceção. Tipo de trap genérica.40 Tabela 4 – Formato das mensagens utilizadas no SNMP Campo Version Community Request-Id Error-status Error-index Descrição Versão do SNMP. Informa os tipos de valores padrões definidos para traps. Quando o Error-status não é zero (ou seja. ou seja. Variable bindings Enterprise Agent-addr Generic-trap Specific-trap Time-stamp Lista de nomes de variáveis e valores correspondentes. a versão definida pela RFC 1157 é 1. Uma variável é uma instância de um objeto gerenciado. Tipo de objeto que gerou a trap. O agente responde este tipo de mensagem com GetResponse. Em alguns casos como na mensagem de GetRequest. Código de trap especifica. e no campo variable bindings são colocados os valores das instâncias . ou valor Specific.

Isto limita o gerenciamento direto de certos equipamentos e exclui outros. As informações enviadas por uma Trap são muitas vezes específicas da implementação. Veja a Figura 2. seja pelo envio de um valor incorreto. foi desenvolvido o conceito de proxy.41 solicitadas.1. O agente também responde essa mensagem com um GetResponse contendo o mesmo request-id do pacote recebido. Ainda. a operação GetNextRequest é atômica.8. bem como as estações de trabalho suportem uma pilha de protocolos em comum. será informado um erro e a operação não será concluída com sucesso. da mesma forma que o GetRequest. 2. existem numerosos sistemas. As operações de GetRequest são atômicas. . A diferença é que para o GetRequest são retornados os valores das instâncias solicitadas. informando um erro se algum dos objetos solicitados não puder ser recuperado. o UDP e IP. ou todos os objetos solicitados são recuperados ou é retornado um erro com o código devido. e são enviadas assim que algum evento de relevância tenha ocorrido na estação gerenciada. mas que não desejam acrescentar o peso do SNMP. ou seja. lógica do agente e dados da MIB em seu sistema. já no GetNextRequest são retornados os valores das próximas instâncias àquelas solicitadas. E ainda. 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. como certos computadores pessoais que implementam o TCP/IP para suas aplicações.8 PROXIES O uso do SNMP exige que todos os agentes. De modo a permitir a gerência de sistemas que não suportam a implementação do SNMP. que não suportem qualquer parte da suíte de protocolos do TCP/IP. as mensagens de Trap não necessitam de nenhuma resposta por parte da estação gerenciadora. seja por erro na sua identificação. sendo que os valores enviados no campo variable bindings são estritamente dependentes da implementação. se alguma das instâncias não puder ser atualizada. o agente SNMP funciona como um proxy para um ou mais equipamentos. Ao contrário das outras mensagens. As mensagens de GetNextRequest são praticamente iguais as de GetRequest. seguindo a ordem lexicográfica dos OIDs (Object Identifier). Ainda seguindo o mesmo padrão das mensagens GetRequest. Neste esquema. como pontes e modems. e a operação de set também é atômica.

a estação de gerenciamento manda requisições para o equipamento onde está o agente proxy. Da mesma forma. pois como já foi dito. permitindo que os nós da rede utilizem o protocolo mesmo não tendo grande poder de . de modo a ficar a par de qualquer modificação no estado do equipamento gerenciado. algum processamento de pooling. ele converte a resposta em uma resposta padrão do SNMP e repassa para a estação gerente. o proxy pode ter. 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.9 AS VANTAGENS DO SNMP A vantagem maior é sua popularidade. podendo utilizar comunicação através do canal serial. pontes. estão disponíveis para dispositivos de rede que variam de computadores. Ainda. 2. paralelo ou mesmo utilizando Ethernet.1 – Gerenciamento utilizando o conceito de proxy Neste caso. Agentes SNMP. Assim que a resposta é recebida pelo agente (proxy).42 Figura 2. adicionado a sua lógica. modems. O SNMP se tornou interoperável. O proxy converte a requisição para o protocolo de gerenciamento que é utilizado pelo equipamento. ao ocorrer algum evento no equipamento. O fato que o SNMP existe com tal apoio dá crença considerável à razão para sua existência. até impressoras. caso o equipamento não tenha a capacidade de informar o proxy na ocorrência de algum evento.8. a mensagem é recebida pelo agente e reenviada no formato das mensagens de trap do SNMP para o gerente.

2. que capturam informações na rede.). string. Expansibilidade é outro benefício do SNMP. e controle de acesso (que restringe o acesso de variáveis particulares a certos . Também. ele pode ser atualizado de forma a adequar-se às necessidades dos usuários futuros. Os tipos de dados da variável (inteiro. já que não necessita de muito tempo para configuração e não exige muito processamento dos nós da rede. Por causa de seu projeto simples. podem ser monitorados e gerenciados. igualmente. é que com a implementação do protocolo SNMP. a maioria destas deficiências pode ser contornada. locais ou não. Estes invasores também podem desligar alguns terminais. O valor da variável. componentes de redes. por causa de seu projeto flexível. pois cada variável contém apenas as seguintes informações: O nome da variável. em princípio. ao transitar por ela. e assim possui falhas. Outro ponto importante. etc. A primeira deficiência do protocolo SNMP é que ele tem grandes falhas de segurança.43 processamento. 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. Conseqüentemente é de mais fácil implementação em redes grandes. E como os agentes SNMP podem ser estendidos para cobrir dados de dispositivos específicos. 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). Contudo. O projeto de sistemas que envolvam estudos em SNMP é mais simples se comparado com outros protocolos de gerenciamento de redes. Se a variável é somente de leitura ou de leitura e escrita. seu projeto simples torna factível (embora não imediato) para um usuário programar variáveis que ele gostaria de monitorar.10 AS DESVANTAGENS DO SNMP O SNMP não é de maneira nenhuma um protocolo de gerência de rede perfeito. verificada na versão SNMPv2. autenticação (impedir os invasores de enviar falsos dados pela rede). A solução para este problema surgiu com a expansibilidade do SNMP. que podem dar acesso a invasores.

memória compartilhada ou arquivos. por usar endereçamento IP. O primeiro passo é implementar a comunicação por TCP/IP. mas é descrita sem nenhuma proteção. e outra password privada permite ao gerenciador fixar valores de variáveis (set).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. se há um problema de roteamento na rede e se um dispositivo não poder ser alcançado. Esse agente interage com o sistema de gerenciamento via SNMP. enquanto o gerente deve ser instalado em máquinas das quais se deseja monitorar a rede. Outros problemas podem ser citados: o protocolo não é muito eficiente.44 usuários. Para a construção do agente. o SNMP provê pouco suporte para esquemas de autenticação. Sempre é verificada a presença de uma das communities em cada mensagem do gerenciador para o agente. Ele suporta apenas um esquema com duas passwords.11 MÉTODOS DE IMPLEMENTAÇÃO Como implementar o protocolo SNMP é uma questão encontrada por muitos administradores de rede atualmente. removendo assim a possibilidade de um usuário derrubar a rede acidentalmente). geralmente dando a cada nó da rede um endereço IP diferente. onde ambos geralmente já devem vir com interface gráfica para facilitar a configuração e a visualização dos dados. e todo dispositivo conectado numa rede gerenciada por SNMP devem ter essas duas communities configuradas. Os agentes devem ser instalados em cada nó da rede. 2. RPC. Qualquer protocolo ou método pode ser empregado: sockets. Não é difícil um invasor descobrir as passwords e influenciar no funcionamento da rede. mas nenhuma especificação existe na interação com o recurso gerenciado. pois há a transmissão de muitos dados desnecessários. deve-se escolher qual será o tipo de agente: extensível . como texto simples. Daí geralmente é só seguir as instruções dos programas para configurar a rede SNMP. Além disso. Uma password pública permite ao gerenciador pedir o valor de variáveis (get). é impossível monitorálo ou reconfigurá-lo. O passo seguinte é adquirir (ou programar) softwares para o agente e o gerente. 2. especificando as MIBs. Essas passwords são chamadas communities. propiciando falhas de segurança. a organização das variáveis na árvore MIB também não é muito eficiente. Na verdade.

Um agente extensível pode possuir vários agentes estendidos. Normalmente um agente extensível é fornecido pelo sistema operacional (Windows) ou por bibliotecas específicas (Unix). para que os agentes estendidos utilizem. A interação com os recursos ainda deve ser feita de forma proprietária. poderá implementar normalmente complementos da MIB II (objetos específicos) e usar o SNMP indiretamente de outro agente. aloca-se a porta UDP 161 e as mensagens são recebidas remotamente.12. 2. Interagem com um agente através de APIs de programação.12. Se ele for estendido.1 TÉCNICAS DE CONSTRUÇÃO USANDO SOCKETS Neste tipo de técnica. têm-se também bibliotecas auxiliares para manipulação de estruturas do protocolo (SNMPAPI). Possuem APIs (Aplication Programming Interface) de programação para outros agentes.45 ou estendido. proxy SNMP para extensão direta do agente e construção de agentes estendidos via API dos agentes extensíveis. Se ele for extensível. Existem basicamente três técnicas especiais de construção de agentes: construção direta via sockets. interagindo com recursos diferentes. Um problema já é resolvido diretamente em um agente estendido: o protocolo SNMP. Além do agente. normalmente já implementa a MIB-II e usam o SNMP diretamente. Figura 2.1 – Uso dos agentes extensivos/estendidos O agente extensível deve implementar o SNMP. .

12.2 – Uso dos sockets 2.3 TÉCNICAS DE CONSTRUÇÃO USANDO AGENTE ESTENDIDO Apenas uma porta usa SNMP no sistema: 161 do agente extensível. que irá implementar objetos extras. além dos objetos de gerenciamento extras.12. Os agentes estendidos são chamados apenas quando necessário. Normalmente. deve implementar o protocolo SNMP. Isto evita a implementação da MIB II. Figura 2.2 TÉNICAS DE CONSTRUÇÃO USANDO PROXY Sobrepõe-se o agente local através de um novo agente.3 – Uso do agente estendido .46 A aplicação deve ser capaz de entender as mensagens que chegar. Essa implementação possui dois problemas: duas portas são usadas para se acessar alguns recursos.12. Figura 2. Cascateamento de proxies e duplo mapeamento em plataformas de uma mesma máquina. 2. A aplicação deve saber enviar traps diretamente a porta 160 remota do gerente associado. as respostas devem ser geradas também de acordo com o protocolo. e chamará o agente original para os objetos anteriores. deve-se implementar a MIB II. Depois das requisições.12. Vários agentes estendidos associados a um mesmo agente extensível. isto é.

47 CAPÍTULO 3 RMON (REMOTE MONITORING) No capítulo 3. trata-se do protocolo RMON e cita-se as suas potencialidades. Faz-se a menção de equipamentos que implementam serviços com esse protocolo de gerenciamento. . São citados os tipos básicos do protocolo RMON: RMON1 e RMON2 e a forma como eles operam. Também se mostra como é vantajoso trabalhar com múltiplos gerentes.

No caso de existirem múltiplos gerentes.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. permitindo. Esses enlaces de rede de longa distância. tais como estações de trabalho. Enviar informações de gerenciamento para múltiplas estações gerentes. Cada elemento RMON tem. tratar e filtrar informações de gerenciamento da rede e apenas notificar à estação gerente os eventos significativos e situações de erro. . Permitir o gerenciamento pró-ativo da rede. mesmo quando a comunicação entre o elemento RMON e a estação gerente estiver temporariamente interrompida. que a causa da falha ou mal funcionamento da rede possa ser diagnosticada a partir de mais de uma estação gerente. cada elemento RMON deve determinar quais informações de gerenciamento devem ser encaminhados para cada gerente. por operarem a taxas de transmissão inferiores às LANs que as interconectam. hubs. os objetivos do protocolo RMON são: Reduzir a quantidade de informações trocadas entre a rede local gerenciada e a estação gerente conectada a uma rede local remota. Possibilitar o gerenciamento contínuo de segmentos de redes locais. das redes locais remotas a função de monitor remoto. Detectar. O protocolo RMON oferece suporte à implementação de um sistema de gerenciamento distribuído. switches ou roteadores. passam a ter grande parte da sua banda de transmissão ocupada para informações de gerenciamento. no caso de situações críticas de operação da rede gerenciada. registrar e informar à estação gerente: condições de erro e eventos significativos da rede. fica atribuída aos diferentes elementos. como tarefas. coletar. então. Nele. Sendo assim. Uma solução encontrada para dirimir este problema foi o Remote MONitoring (RMON). diagnosticando e registrando eventos que possibilitem detectar o mau funcionamento e prever falhas que interrompam sua operação. analisar.

Detecção de Problemas e Geração de Relatórios . estes podem ser usados para executar diagnósticos continuamente e para analisar a performance da rede.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. Uma organização pode dispor de diversos destes dispositivos. A especificação RMON é uma definição de uma MIB. é definir padrões de monitoração e interfaces para a comunicação entre agentes/gerentes SNMP. o monitor pode notificar a estação de gerenciamento e armazenar o histórico estatístico referente à falha. os dispositivos RMON podem fazer uma análise significativa dos dados que coletam. O monitor pode também notificar a estação de gerenciamento se eventos excepcionais ocorrerem. Quando uma destas situações ocorrer.o monitor pode ser configurado para reconhecer certas situações. 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. Monitoramento Preemptivo .esta é a condição em que a estação gerenciadora não está em contato constante com o dispositivo RMON. o monitor pode registrá-la e reportá-la a estação de gerenciamento. Desta forma. O objetivo. . um por segmento de rede. para gerenciar sua rede Internet.WAN) ou para acidentes onde as falhas na rede afetam a comunicação entre a estação gerenciadora e os dispositivos RMON. o monitor é configurado para coletar estatísticas e fazer diagnósticos continuamente. mais notadamente condições de erro e checar continuamente por elas. Muitas vezes estes dispositivos são dedicados e devotam significativos recursos internos para o propósito de gerenciamento de rede.se o monitor tiver recursos disponíveis.49 3. Presta-se para desenhar redes de baixo custo de comunicação (redes por acesso discado ou conexões com Wide Area Networks . Análise de Dados . Quando uma falha ocorrer. são os que se seguem: Operação Off-Line .por serem dispositivos dedicados exclusivamente ao gerenciamento de rede e por estarem localizados diretamente no segmento monitorado da rede. mesmo se a conexão com o gerente não for possível ou apresentar falhas. contudo. Os objetivos da implementação de um dispositivo RMON.

A definição da MIB RMON contém características que suportam controle extensivo da estação de gerenciamento.1.uma configuração de rede pode ter mais de uma estação gerente para dar mais confiabilidade. . A configuração dita o tipo e a forma de dados para serem coletados. Por exemplo. estes dispositivos podem determinar qual host gera maior tráfego ou mais erros na rede. o monitor é capaz de efetuar operações mais complexas. Os parâmetros são configurados pela adição de um novo registro na tabela ou alterando uma existente. tipos de dados.50 Por exemplo. a estação gerente envia os parâmetros apropriados para configurar o monitor remoto para coletar os dados desejados. executar funções diferentes e prover capacidades de gerência para unidades diferentes dentro da organização. A MIB é organizada em grupos funcionais. Múltiplos Gerentes .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. que é somente para leitura. Isto causa a retirada daquela entrada e de todos os registros associados em tabelas de dados. um monitor remoto necessitará ser configurado para coletar dados. A estação gerente pode então criar um novo registro de controle com os parâmetros modificados. os registros das tabelas de dados associadas são apagados. 3. Assim. Quando um registro da tabela de controle é apagado. uma tabela controle pode conter objetos que especifiquem a origem dos dados coletados. Cada grupo terá uma ou mais tabelas de controle e uma ou mais tabelas de dados. Desse modo. e os recursos usados pelos registros são recuperados. Para modificar qualquer parâmetro na tabela de controle é necessário primeiro invalidar a entrada. O mesmo mecanismo é usado para apenas desabilitar uma coleção de dados. funções para serem executadas pelo monitor são definidas e implementadas na tabela. Estas características dividem-se em duas categorias: Configuração Tipicamente. Uma tabela de controle contém parâmetros que descrevem o dado na tabela de dados. Configurado como dispositivo dedicado.

prevenindo seu uso por outras funções gerente desejadas por outras estações gerentes. uma combinação de características de resolução e prevenção é necessária. Esta é uma característica potencial para conflitos e pode gerar resultados inesperados. assim que uma ação específica é alcançada se o objeto é setado para um valor específico.1. SNMP tem apenas capacidade de ler valores de objetos e setar valores de objetos com visão MIB. Recursos podem ser designados para uma estação gerente onde ocorreu uma falha e os recursos não foram liberados. Um operador pode ter autoridade para liberar recursos que outro operador tenha reservado. Em geral.2 . No caso de agentes RMON compartilhados. estes objetos representam estados. isto é possível para usar o conjunto de operações SNMP para emitir um comando. 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: Uma estação gerente pode reconhecer recursos próprios. Uma estação gerente pode capturar e ocupar recursos de monitor por um longo período de tempo. Contudo. Um objeto pode ser usado para representar um comando. A qualquer tempo acessos concorrentes são permitidos para um recurso disponível em um agente. Ela pretende que uma simples característica na MIB RMON suporte estes requerimentos. as seguintes dificuldades podem surgir: Requisições concorrentes podem exceder a capacidade do monitor para fornecer estes recursos.Múltiplos Gerentes Conforme já citado. Um número desses objetos é incluído na MIB RMON. 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. . Para proceder com esses problemas. um agente RMON pode ser submetido a múltiplos gerentes.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. 3. e uma ação é executada se a estação gerente trocar o estado (pela troca do valor do objeto).

ou seja. um monitor será configurado com um conjunto padrão de funções que serão setadas quando ele for inicializado. os dispositivos RMON1 não distinguem o tráfego neste segmento originado através de um roteador. o que é uma grande deficiência. O RMON1 opera somente na camada Media Access Control (MAC) e. funcionalmente complementares. Se múltiplos gerentes de rede têm acesso à tabela de controle. Isto também significa que.52 A especificação sugere que o rótulo proprietário contenha um ou mais desses atributos: endereço IP. Os registros de controle que definem estas funções são propriedades do monitor. a estação gerente que seja proprietária de uma tabela de controle pode modificar ou apagar aquele registro a qualquer hora. Quando uma estação gerente quer utilizar uma certa função no monitor. Apesar do rótulo ser proveitoso. Por convenção. a estação gerente pode compartilhar a função simplesmente observando os registros de dados read-only associados com o registro de controle. localização ou telefone. Assim. nome da estação gerente. o fato do RMON1 só trabalhar na camada MAC. Freqüentemente. significa que o este somente apresenta estatísticas para tráfego agregado . muitas aplicações usuais como uma medição do tempo de resposta cliente/servidor . ela precisa verificar a tabela de controle relevante para ver que função tem sido definida por outra estação gerente. por não serem capazes de monitorar a camada de rede. Neste caso. 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”. 3.2 . Contudo. "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. cada rótulo relevante é configurado com uma cadeia de nome "monitor". é importante ressaltar que o rótulo não tem ação como uma senha ou mecanismo de controle de acesso. Porém. nome do gerente de rede.RMON1 e RMON2 Dois padrões básicos de protocolo RMON são especificados: RMON1 e RMON2.porém não apresenta estatísticas para camadas diferentes de várias pilhas de protocolos. uma maior eficiência pode ser alcançada pelo compartilhamento.

associando pares de endereços MAC de elementos de rede.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. foram especificados dez grupos básicos de variáveis. Filtro . tráfego e taxas de erros ocorridos em um segmento de rede. 3. 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.contém informações de utilização da rede e taxa de erros na forma de matriz.define condições associadas a pacotes trafegados pela rede. não é possível através deste protocolo unicamente.permite classificar os hosts segundo critérios pré-definidos como. a RMON-MIB.possibilitam estabelecer condições limites de operação de uma rede que deve provocar a geração de alarmes. que incluem: Estatístico .contêm informações relativas ao tráfego gerado e recebido pelos hosts conectados através da referida rede. empregadas na análise do comportamento de uma rede e que oferecem subsídios para um gerenciamento pró-ativo.Grupos da RMON1-MIB Para a RMON1-MIB. por exemplo.mantém estatísticas de utilização. no nível da camada de rede e camadas superiores. por sua vez.1 .permite controlar o processo de amostragem (definição dos intervalos de amostragem) de informações do grupo estatístico e registrar tais informações. Hosts .53 ou uma provisão de estatística para as sete camadas. complementando. Classificação de n hosts (top n hosts) . Alarmes . associada a cada elemento RMON da rede. que uma vez satisfeitas implicam captura de tais pacotes pelo elemento RMON ou no registro de estatísticas baseadas nos mesmos. O RMON2 opera.3. Histórico . Matriz . . portanto o RMON1.3 . determinar quais os hosts conectados através da rede que geram maior tráfego em um dado período do dia.

como é o caso do grupo de "classificação de n hosts" em relação ao grupo de hosts. que incluem: Diretório de Protocolo . Matriz da Camada de Aplicação .determina como devem ser capturados os dados dos pacotes trafegados pela rede.contabiliza o tráfego. .de rede. foram especificados. transporte e de camadas superiores .especifica uma lista dos protocolos .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. 3. remover ou configurar entradas dessa lista. cujos endereços de rede são conhecidos pelo RMON. também. Matriz da Camada de Rede . dez grupos básicos de variáveis.contabiliza o tráfego existente entre um par de hosts. cujos endereços de rede são conhecidos pelo RMON. Histórico do Usuário . gerado e recebido por um host. relativo a determinado protocolo. Evento . entre outras informações. embora exista uma relação de dependência entre alguns deles. A implementação de todos os grupos é opcional. Mapeamento de Endereços .54 Captura de Pacotes .3.2 . Camada de Aplicação do Host . cujo endereço de rede é conhecido pelo RMON. conforme. existente entre um par de hosts. 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. período e intervalos de amostragem.ou endereços IP.contabiliza o tráfego. são capturados os cem primeiros bytes dos pacotes filtrados pelo elemento RMON. relativo a um determinado protocolo.contém a configuração dos parâmetros de operação do RMON.contabiliza o tráfego gerado e recebido por um host.Grupos da RMON2-MIB Para a RMON2-MIB. Configuração do Probe . Como default.que o elemento RMON tem a capacidade de monitorar.contém informações específicas de um usuário relativo ao tráfego gerado. a serem enviados aos gerentes. Camada de Rede do Host . cujo endereço de rede é conhecido pelo RMON. sendo possível incluir.relaciona endereços MAC e endereços de rede .

Switch Nways Ethernet 8271.Modelo 216. 3.define os requisitos de conformidade da RMON-MIB.55 Conformidade RMON . . Switch Nways Ethernet LAN 8271 – Modelo 612.4 EQUIPAMENTOS QUE IMPLEMENTAM RMON Os equipamentos a seguir possuem recursos para a utilização do protocolo RMON: Switch Nways Ethernet LAN 8271 – Modelo 712.

A estrutura de árvores é comentada como uma forma de organização em níveis. fala sobre a MIB e suas propriedades relacionadas ao armazenamento de dados (variáveis) para estudo. . Explica-se como a MIB pode ser construída e definida (bases geradas pela definição da SMI).56 CAPÍTULO 4 MANAGEMENT INFORMATION BASE (MIB) O capítulo 4.

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

ele também serve como identificador da estrutura dos objetos.1 – Árvore da MIB gerada pelo MIB Browser Foi definido que o nodo Internet tem como identificador 1. incluindo entradas individuais em tabelas. veja a Figura 4. e serve de prefixo para os demais nodos definidos nesse mesmo documento: directory: reservado para uso futuro para OSI.org. este identificador também serve como nome do objeto. ou informação relacionada que deve ser gerenciada.1. 4. viabilizando a consulta das informações de forma mais direta com o uso do SNMP. Cada objeto na MIB possui um identificador do tipo ASN. Como exemplo dessa estrutura utilizada na MIB. gerada pelo aplicativo MIB Browser. escalares e matrizes bidimensionais de escalares.1. iso.58 informações de gerenciamento (SMI). sendo que cada um deles representa um recurso. Os objetos das folhas da árvore representam os atuais objetos gerenciados. Figura 4. Este software é de simples gerência.1.internet.6. . Devido à forma hierárquica de escolha desse nome.3.1 OBJECT IDENTIFIER. da empresa MGSoft.dod.1. A MIB suporta somente tipos de dados simples. ou seja. apresentando uma estrutura visual para a estrutura de dados da MIB. o qual também suporta apenas tipos escalares simples de dados.1 ESTRUTURA DA MIB Todos os objetos gerenciados no SNMP são arranjados em uma estrutura hierárquica do tipo “árvore”. Ele é capaz de mostrar os valores das instâncias dos objetos que são mostrados na árvore MIB. uma atividade.

No caso de expansão. passando pela aprovação dos órgãos competentes. incluindo "sistemas" e "interfaces". private: utilizados para identificar objetos definidos unilateralmente. eles são organizados hierarquicamente com um específico dígito associado por diferentes organizações. Identificadores de objetos são como números de telefones. MIB III). atualmente. esta porção da subárvore é utilizada para permitir que os fabricantes possam aprimorar o gerenciamento de seus equipamentos. A subárvore private tem. e outros) e outras categorias. IP. logo a seguir: . Fabricantes podem definir suas próprias ramificações para definir instâncias em seus produtos.59 mgmt: utilizado para objetos definidos nos documentos aprovados pelo IAB. Abaixo da subárvore MIB II estão os objetos usados para obter informações específicas dos dispositivos da rede. e posteriormente. Extensões privadas podem ser adicionadas na subárvore private. Os níveis da árvore são compostos pelos ítens de dados individuais. serem colocados no ramo mgmt. ou mesmo completamente substituída por uma nova versão (por exemplo. podem. enterprises. que estão presentes na Tabela 5. experimental: usado para identificar objetos utilizados apenas como experimento na Internet. SNMP. Estes objetos são agrupados por protocolos (incluindo TCP. Esses objetos estão divididos em 10 grupos. A MIB e a MIB-II padrão para a Internet. Identificadores de objetos (OID) identificam ou nomeiam unicamente os objetos da MIB na árvore. contém 171 objetos. A árvore MIB é extensiva por força das ramificações experimentais e privadas. Uma MIB experimental pode ser construída para uma aplicação em especial. UDP. Objetos adicionais podem ser definidos para a MIB II de três formas diferentes: A subárvore MIB II pode ser expandida. Uma MIB pode ser descrita como uma árvore abstrata com um root anônimo. Esses objetos inicialmente são colocados no ramo experimental. precisa-se apenas criar um novo nodo abaixo da MIB II. apenas um nodo filho.

1.3.1. sysContact (1.2.3.1. Pode incluir o nome e a versão do hardware.3.1.1): Descrição textual da unidade.1): Número de interfaces de rede (não importando seu atual estado) presentes neste sistema.4): Texto de identificação do gerente da máquina gerenciada e como contatá-lo.1.2.6.6.6. ifOperStatus (1.1.1.1.1.2.1.1. .3.2) ifNumber (1.2.1.3): Tempo decorrido (em milhares de segundos) desde a última re-inicializaçãodo gerenciamento do sistema na rede.6. sistema operacional e o programa de rede.3.1.2.6.6.2.2.1.3.2.3.2. sysUpTime (1.6.10): Número total de octetos recebidos pela interface.1. ifInOctets (1.1.60 Tabela 5 – Grupos estudados na MIB Grupo system Interfaces at ip icmp tcp udp egp transmission snmp Informação informações básicas do sistema interfaces de rede tradução de endereços protocolo ip protocolo icmp protocolo tcp protocolo udp protocolo egp meios de transmissão protocolo snmp Alguns dos objetos pertencentes aos grupos da MIB II são: Grupo System (1.2.8): Estado atual da interface.1) sysDescr (1.2.6.1.1.3.1.2.1.2.1. Grupo Interfaces (1.

3.1.1.2.1.2): Número da porta do usuário UDP local.6.1.3.3.4) ipForwarding (1. udpNoPorts (1.3.1.2.6.6) tcpMaxConn(1.4): Número máximo de conexões TCP que esta entidade pode suportar.6.7.2.2.3.5.1.5) icmpInMsgs (1.7.2.1.6.2.7.3.3.1): Indica se esta entidade é um gateway.1.5.4): Número de datagramas que foram recebidos e descartados devido a erros no cabeçalho IP.1.1.1.6.2.6.2.1.12): Número total de segmentos retransmitidos.3.3.3): Número total de datagramas recebidos pelas interfaces.9): Número de conexões TCP que estão como estabelecidas ou a espera de fechamento.6.11) .4.1.1. ipInHdrErrors (1.1.5.6.1.1.1.1.6.1.1.3.1. icmpOutMsgs (1.1.6.14): Número total de mensagens ICMP enviadas por esta entidade.4.2.6.1.2.7) udpInDatagrams (1.6. Grupo SNMP (1.1.6. Grupo TCP (1. Incluindo aquelas com erros.2.2): Número total de datagramas UDP recebidos para os quais não existia aplicação na referida porta.1.61 Grupo IP (1. Grupo ICMP (1.2.3.2.6.4.2.3.3.3. tcpCurrentEstab (1.6.6. Grupo UDP (1.6.3.2. udpLocalPort (1.6. incluindo os recebidos com erro.1): Número total de datagramas UDP entregues aos usuários UDP.3.2. ipInReceives (1.1.1.6. Incluindo aquelas com erros.1): Número total de mensagens ICMP recebidas por esta entidade.1. tcpRetransSegs (1.1.

6. Uma instância de objeto especifica uma entidade particular de um tipo de objeto que tem associado um determinado valor. Ela identifica os tipos de dados que podem . deve-se usar a notação ASN.2 DEFINIÇÕES DE OBJETOS A MIB é formada de objetos.1. enquanto que uma instância da macro define um tipo específico. Valor de uma instância de macro: representa uma entidade específica com um valor específico. De modo a definir objetos para estender a MIB.2): Número total de mensagens enviadas pela entidade SNMP. especifica a sintaxe do conjunto de tipos relacionados.3.2. O tipo de objeto. Desta forma.1. 4.1. que é uma descrição sintática.1.13): Número total de objetos da MIB que foram resgatados pela entidade SNMP. uma instância de macro define um novo tipo de dado. a qual agrupa um conjunto predefinido de tipos de dados e uma gramática para definir novos tipos que são derivados dos existentes. tem-se os seguintes níveis de definição: Definição da macro: define quais são as instâncias legais. 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. definida na RFC 1155. A definição da macro fornece a sintaxe para um conjunto de tipos relacionados.3 DEFINIÇÕES PARA SMI A SMI (Structure of Management Information). especifica como uma MIB pode ser definida e construída. 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.1. snmpInTotalReqVars (1.1. define um tipo particular de objeto gerenciado.6. 4.11.2.62 snmpInPkts (1. snmpOutPkts (1.1): Número total de mensagens recebidas pela entidade SNMP.6.2.11.3.11.1.3. sendo que cada objeto possui um tipo e um valor.

O nome é o identificador de objeto. porém atrelados a um valor máximo.representa uma codificação arbitrária.1 primitivos: Inteiros . Os tipos de dados SMI são divididos em três categorias: tipo simples. inclusive o zero. 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. 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. Tipos de dados de grandes aplicações referem-se aos tipos de dados especiais definidos pelo SMI: Endereços de rede .inteiros não negativos que são incrementados ou decrementados. O tamanho da fila de saída de pacotes é um exemplo. inteiro ou string).o tempo de um evento. . A SMI procura a simplicidade e a escalabilidade. Identificadores de objetos .seqüência ordenada de zero ou mais octetos. Checagem de tempo . Ela especifica que todo objeto gerenciado deve ter um nome. Os tipos simples incluem quatro tipos ASN. A sintaxe define o tipo de dados dos objetos (por exemplo.inteiros não negativos são incrementados de um em um até atingirem um valor máximo.valores negativos ou positivos de todos os números.conjunto de todos os identificadores de objetos alocados de acordo com as regras especificadas pelo ASN. Medidas . Um subconjunto da definição ASN. chamada Base Encoding Rules (BER).1. Contadores .representam um endereço de uma família particular de protocolos. Opaco .63 ser utilizados na MIB e especifica como os recursos são reapresentados e nomeados. O número total de bits recebidos em uma interface é um exemplo de contador. O tempo necessário para uma interface chegar ao estado corrente é um exemplo. quando eles são resetados e voltam a zero. tipo de grandes aplicações e tipo construtor simples.1 é usado para a sintaxe SMI. Cadeia de octetos . Outra especificação ISO. uma sintaxe e um código. detalha os códigos SMI.

1. Ele é útil quando os valores são sempre não negativos. Este tipo de dados redefine o tipo de dados simples "inteiro" do ASN.referência a uma linha de uma tabela. Inteiros sem sinal . porém uma precisão determinada no SMI.1. que tem uma precisão arbitrária no ASN. Tabela .64 Inteiros .1. Cada elemento de uma linha pode ser um tipo simples ou um tipo de grandes aplicações.representa uma informação com valores inteiros sinalizados. porém uma precisão determinada no SMI. que tem uma precisão arbitrária no ASN.representa uma informação com valores inteiros não sinalizados. Este tipo de dados redefine o tipo de dados simples "inteiro" do ASN.1. . Cada linha pode ter um número qualquer de colunas.referência a uma tabela com zero ou mais linhas. O tipo construtor simples inclui dois tipos ASN.1 que definem múltiplos objetos em tabelas e listas: Linha .

65 CAPÍTULO 5 ESTUDO DE CASO Neste capítulo. Procurou-se enfocar os pontos chaves utilizados no trabalho. foi feito um estudo de caso com a aplicação do SNMP sendo realizada conjuntamente com Controladores Lógico-Programáveis. das quais. sem abordar muito a parte de configurações. No texto. uma serviu como base para sua implementação. pela UFRS em dezembro 1999. foi exposto algumas propostas sugeridas por Alexandre. diplomado em Ciências da Computação. que foram próprias do autor original. Este estudo tem como base o projeto realizado pelo estudante Alexandre Cervieri. .

geração de relatórios e controle supervisório. De forma a permitir a integração entre os softwares de gerência e os controladores. onde seja necessária uma baixa ocupação de espaço físico e haja uma grande quantidade de dados. tornou-se uma prática comum que nos grandes sistemas industriais houvesse uma interligação de vários controladores programáveis utilizando essas redes. 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. de forma a poder criar uma MIB genérica de controle. O avanço tecnológico aumentou muito as suas funcionalidades. 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. Os CLPs se adaptam a sistemas que precisam de uma grande confiabilidade. temporização.66 5. contagem e aritmética para o controle de máquinas e processos.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. Além dos controladores. acrescentando às suas aplicações: funções de controle de variáveis. Alexandre Cervieri. Procurou-se elementos que fossem comuns a todos os controladores utilizados como casos de estudo. entre outros.3 PROPOSTA DE MIB Para construção da MIB. como dispositivos de entrada e saída analógicos e digitais. 5. Com o desenvolvimento das tecnologias de redes de computadores. aquisição de dados. o autor do projeto. lógica. necessitando de equipamentos que permitam uma fácil e não traumática expansão. possui-se ligados a essas redes vários módulos acessórios.2 .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. dispositivos de terminal para interação com o usuário. Alexandre buscou inicialmente a identificação dos elementos fundamentais que poderiam ser gerenciados remotamente. e não somente para atividades de controle repetitivas que envolvem temporização simples. e sequenciamento de entradas e saídas discretas. .

67 A forma de organização da MIB foi feita dividindo-a em objetos de gerenciamento específicos genéricos.5. 5. O controlador já possuía suporte aos protocolos da pilha TCP/IP. extremamente ligadas a limites de tempo bem determinados. seguindo o modelo adotado pela MIB II. a inserção do software agente não afetaria de forma muito significativa o funcionamento do resto do sistema. proporcionando uma economia nos gastos. assim como apresentado na Figura 5.5. conforme a Figura 5. caso contrário suas atividades de controle do controlador.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. mesmo sendo um módulo em separado dedicado à troca de mensagens. Neste caso.5. .1. estariam prejudicadas. Existem famílias de controladores que não possuem nem mesmo interface de rede Ethernet.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. os quais seriam maiores se cada controlador tivesse que ser equipado com o agente completo.5 ALTERNATIVAS DE IMPLEMENTAÇÃO DO AGENTE 5. e por esse motivo dependem de módulos de comunicação auxiliares. pilha de protocolos TCP/IP e todo o hardware que porventura fosse necessário acrescentar para a sua implementação. uma solução seria implementação do agente SNMP nestes módulos.2. O autor do projeto procurou não alterar a temporização das atividades. Como normalmente eles já apresentam a pilha de protocolos TCP/IP.

foi desnecessária a instalação de qualquer interface gráfica para o LINUX.5. aliadas a relativa simplicidade de implementação de um agente em um sistema operacional de mercado. ou seja. muito utilizado pela .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. seja Get.1. Dessa forma.0. Tais vantagens. FreeBSD. GetNext ou Set. como KDE. Microsoft Windows 95/98. fizeram com que esta fosse a solução adotada neste trabalho. versão 4. foi adotada a solução de um agente do tipo Proxy. 5. O pacote básico escolhido foi o UCD-SNMP. Gnome entre outras. ou outro existente e implementaria o SNMP e também o protocolo proprietário existente no controlador. Uma das possibilidades de implementação do agente sugerida foi a criação de todos os procedimentos referentes ao recebimento de mensagens SNMP. LINUX. com um sistema operacional Microsoft Windows. mas apenas através do software gerente. foi o sistema operacional usado. O LINUX da distribuição Conectiva. tornando possível a economia de alguns acessos ao controlador. A preocupação quanto às implicações temporais continuaram. recebimento e interpretação dos pacotes. dos OIDs e execução dos procedimentos cabíveis para cada tipo de mensagem. servindo como um gateway entre eles. escuta na porta padrão. como apresentado na Figura 5. Este agente poderia ser implementado. em um computador pessoal. pois a interação agente/usuário não seria feita localmente.6. Assim. mas em um sistema como esse seria possível o uso de alternativas de armazenamento temporário de certas informações no computador. descartaram-se os sistemas operacionais como Microsoft NT.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. Para a execução do agente não se teria a necessidade de uma interface de janelas. versão 3.3.5. portanto.

5. pois implementa as versões 1. Um agente estendido pode ser criado utilizando qualquer umas dessas versões.6 – IMPLEMENTAÇÃO DO SOFTWARE AGENTE A Figura 5. o qual interpreta a MIB e gera as estruturas de dados e funções básicas para a implementação da MIB. 2 e está em desenvolvimento a versão 3 do SNMP. . Assim. 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.69 comunidade LINUX. O suporte a agentes estendidos indica que quando o UCDSNMP está realizando a interpretação dos OIDs. Da mesma forma que a interpretação dos pacotes e dos OIDs. as tarefas de receber as mensagens da porta UDP padrão do SNMP fica a cargo do pacote UCD-SNMP. 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. 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. Com a utilização desse pacote. 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.1.6.

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

do projeto FreeNMS. primeiramente de uma forma geral e posteriormente. foi feito um restrição aos aplicativos MRTG e WhatsUP. depois de enfocadas as suas propriedades. também. trata-se dos softwares de gerenciamento.71 CAPÍTULO 6 SOFTWARES DE GERENCIAMENTO SNMP/RMON No capítulo 6. . Trata-se. em desenvolvimento pela PUC do Rio Grande do SUL.

2 PLATAFORMAS DE GERENCIAMENTO Uma plataforma de Gerenciamento pode executar várias aplicações de gerência de desempenho. tais como cabos abertos e mau funcionamento em hardware de conexão. rotinas de acesso a MIB dos agentes utilizando o protocolo de gerência. monitores de rede. por exemplo. pelo menos. devido à complexidade no gerenciamento. visualizar graficamente a evolução com o tempo dos valores das variáveis dos agentes. uma base de dados de tecnologia. 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. Existem basicamente quatro tipos de ferramentas: ferramentas a nível físico. sistemas de gerenciamento de redes integrados (SGRI). 6. analisando o tráfego na rede. Todas devem. Há um aplicativo muito utilizado com este tipo de aplicação chamado MIB Browser. editores gráficos de topologias. Contém uma aplicação simples de gerência que permite. capturando e decodificando pacotes e sua transmissão em tempo real. que auxiliam no rastreamento e correção de problemas encontrados nas redes. todas devem ter mecanismos de conversa com agentes através do protocolo de gerência.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. monitorando o tráfego. saber a topologia de rede. armazenamento dos valores recebidos dos agentes numa base de dados.72 6. que detectam problemas em nível de cabos e conexões de hardware. Uma plataforma de Gerência é um software especial que possui as seguintes características: Contém toda a funcionalidade comum a várias aplicações de gerenciam: algoritmos de autoconhecimento de topologia. etc. todas devem ter formas simples de apresentar informação gráfica ao usuário. O principal objetivo dos softwares de gerenciamento é auxiliar o gerente de uma rede no monitoramento e detecção de problemas. tendo estes pontos em comum. . os quais permitem o monitoramento e controle de uma rede inteira a partir de um ponto central. que se conectam a redes. Analisadores de rede.

browsers como o Tk/Tcl Mib Browser. Por exemplo. JDMK. como o SNMPPerl. etc. como o SMIC. 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. O sistema já se encontra em fase de testes e tem alcançado resultados plenamente satisfatórios em duas grandes operadoras locais. Ferramentas mais completas são oferecidas para manter e monitorar configurações distintas de grandes redes. Através destes gráficos podem ser feitos levantamentos do perfil do tráfego. através de contratos SLA (Service Level Management). IBM. Existem também muitos utilitários para MIB. como C ou até mesmo Java. Agentes e gerentes podem ser programados com diversas linguagens.3 – O PROJETO FREENMS O projeto FreeNMS – Free Network Management System. o SMICNG e o SNACC. verificando a performance do equipamento e o tráfego total em um agente SNMP. uma solução é o programa Scotty. O FreeNMS trata-se de um Software Livre para Gerência de Redes. a HP oferece o pacote Open-View e a Sun oferece o Sun-Net Manager. usando pacotes específicos como JMGMT. funcionalidades de acompanhamento de . 6. usando SNMP (Simple Network Management Protocol) e outras tecnologias para a gerência automatizada e integrada de grandes redes. preferencialmente baseada na WEB. Há também linguagens de programação específicas para SNMP. 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. Como diferencial. Ambas são pagas. possui além das características tradicionais de uma Plataforma de Gerência de Redes.73 Apresenta uma interface amigável com o usuário. Livre de plataforma. JMAPI. permitindo que qualquer usuário interaja sem necessidade de treinamento. Monitoramento do tráfego em um agente através de gráficos. MIBs específicas como as da Cisco. Compiladores. Mas a maneira mais fácil de se fazer um agente é customizar um agente extensível. podendo assim gerenciar qualquer dispositivo independente da plataforma. De domínio público.

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. A solução desenvolvida para este problema no FreeNMS foi a concepção de pollers distribuídos. permitindo que pollers também estejam geograficamente distribuídos. semanal. Em ambientes com muitos equipamentos. é possível realizar um levantamento sobre todo o histórico. Mapa gráfico da rede gerenciada. No FreeNMS. foi desenvolvida uma arquitetura de Banco de Dados distribuído. O modelo tradicional de um NMS (Sistema de Gerência de Redes). com status de nodos up e nodos down. Desta forma. consiste em uma aplicação Gerente requisitando informações dos Agentes. o acúmulo de tráfego neste segmento seria tão grande que traria sérios problemas para a própria rede gerenciada. O FreeNMS realiza coletas periódicas de diversas informações dos equipamentos gerenciados e armazena-os na base de dados da aplicação. diário. 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. Detecção imediata de falha de rede em equipamentos (nodes down). Em muitos casos os Agentes também tomam a iniciativa de se comunicar com o Gerente. tentativas de acesso forçadas com senhas erradas etc). Através da análise destes dados é que relatórios são gerados e alarmes de quebra de SLAs são disparados. Lista-se abaixo. Realizar Descoberta de Rede (Network Discover) e detecção automática e constante de novos (ou retirada de) nodos da rede. As requisições das informações de gerência são em espaços de tempo prédeterminados. através da geração de relatórios e gráficos estatísticos. enviando alarmes (denominados traps) sobre um evento anormal (queda de link. sobre o funcionamento atual.74 Qualidade de Serviços (QoS) contratados (contratos estes denominados SLA – Service Level Agreement). Estas bases distribuídas por sua vez são replicadas e atualizam o banco de dados “central”. as funcionalidades básicas do sistema FreeNMS: Geração de Relatórios e Gráficos diversos sobre o status da rede. . 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. mensal e anual. que então é o que acumula as informações totais da rede.

Ele pode funcionar através de uma plataforma Unix/Linux e Windows NT Como requisitos de máquina. Primeiramente. 16 MB de memória. As páginas HTML geradas utilizam imagens GIF atualizadas em um determinado período de tempo.4 – MRTG (MULTI ROUTER TRAFFIC GRAPHER) O MRTG é um programa que gera páginas HTML. e aos gráficos que são montados utilizando arquivos no formato GIF. Basicamente o Multi Router Grapher – MRTG é uma ferramenta para monitorar o tráfego na rede. é necessário ter um HD de boa capacidade. utilização de CPU e qualquer outra variável numérica de equipamentos que suportem estas características de gerenciamento. antes de instalar o MRTG. Estas páginas representam os dados obtidos dos dispositivos gerenciados. Independência do SGBD (Sistema Gerenciador de Banco de Dados). devido aos logs que o MRTG gera. Sistema totalmente desenvolvido com (e para) Softwares Livres. Após ter instalado devidamente o mrtg deve-se proceder à sua configuração. A Figura 6. a utilização de interfaces. 6. é precisa ter um servidor HTTP instalado na estação onde se pretende instalá-lo. Sistema Coletor (poller) multi-thread de coleta de variáveis SNMP e status. E depois disso. Permite a criação de Usuários e Domínios de Gerência.4. . instalar o pacote via aptget. Atualmente suporte aos bancos PostgreSQL e MySQL. links de redes. onde apresenta dados de monitoração provenientes de variáveis de gestão nos equipamentos.75 Interface totalmente baseada na Web (Web-based).1 mostra gráfico gerado com o uso do MRTG. Permite a existência de pollers distribuídos (gerência distribuída). Para poder visualizar os dados deste aplicativo. temos como configuração mínima: Pc 486 DX 100/66 MHz.

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

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

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

5. bip ou execução de algum programa. para uma ou para um grupo de pessoas. Pager.5 – Guia Alerts .4 – Guia Services Guia Alerts: As notificações podem ocorrer através de alarmes sonoros.80 Figura 6. Figura 6.5. e-mail. traps SNMP.

Há uma notificação quando um host/serviço ficou Down e também quando este voltou a ficar UP. previamente configuradas nos agentes. Figura 6. O Whats Up receber estas traps. Esta funcionalidade é importante. As notificações chegam ao WhatsUp e este como forma de alerta envia uma mensagem para o administrador com o(s) problema(s). basta configurar a porta de escuta no WhatsUp. pois permite ao administrador verificar possíveis problemas que estejam acontecendo nos dispositivos gerenciados de uma máquina qualquer. 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. O WhatsUp permite ainda enviar e-mails para celular.81 Para realizar uma notificação via trap. Guia Notes: Nesta guia é onde estão as informações gerais a respeito de um determinado host. A notificação por e-mail é de grande utilidade.6 – Guia Notes . O único problema das mensagens por e-mail é o excessivo número de mensagens geradas.5. permitindo que o administrador saiba imediatamente quando um determinado problema ocorreu estando ele onde estiver.

Finger. SNMP. ano. ao clicar-se nele. Traceroute. novas funções/guias estarão incluídas. e permite configurar aplicações de FTP e Telnet. exibindo a melhor e/ou pior disponibilidade. Uma outra característica deste software é o fato de gerar relatórios de eventos. Scan. facilitando assim o trabalho do administrador. ou quais os dias em que houve mais tráfego na rede. 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. Estas ferramentas podem ser utilizadas para analisar o comportamento de objetos gerenciáveis. Whois. que pode identificar os dias (dia. Este gráfico de desempenho demonstra os dados agregados a um determinado dispositivo. . e Throughput. LookUp. Quote. mês.5.82 Guia Menu: A ferramenta inclui os serviços: Ping. Figura 6.7 – Guia Menu Depois de criado o host. LDAP. hora) em que houveram problemas em um determinado host.

ethz. http://ucd-snmp.nu 95/98/NT/2000 e Computer Oetiker e muitos staff.com Linux Windows 95/98/NT/2000 Windows 95/98/NT/2000 e Advent http://www.networkview.com Linux Windows 95/98/NT/2000 e Advent http://www.ucdavis.html http://eeOetiker e muitos staff.ipswitch.com Site do Fabricante http://www.adventnet.equival.ethz.adventnet.ch/~oetiker/webtools/eedtoll .com Plataforma Windows Fabricante Woodstone Consulting IPSwitch http://www.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 Servers Alive Whats Up AdvanNet V5 Monitor AdvanNet SNMP Utilities Network View UCD SNMP Linux MRTG Unix/Linu x e Windows NT RRDTools Unix/Linu x e Windows NT MIB Master Linux Windows 95/98/NT/2000 e e Linux Windows 95/98/NT/2000 Windows 95/98/NT/2000 e of Davis Tobias contribuintes Tobias contribuintes Equivalenc http://www.woodstone.ch/~oetiker/webtools/mrtg/m View University Califórnia.com http://eertg.edu Network http://www.

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. aumentar-se-á a segurança quanto a disponibilidades do serviço. Nesse trabalho. Isso será importante para as empresas que fazem os seus negócios pela Internet: compras. Além disso.Porém. garantindo a melhor qualidade de seus serviços. Mostrou-se os programas que serviram de base para as aplicações.SNMP/RMON. Isto posto. consultas. surgindo à necessidade de utilizar sistemas de gerenciamento eficientes para garantir sua interoperabilidade. pode-se observar que futuramente este poderá ser usado para monitorar os recursos da Internet em nível de WAN. há entre vários outros modelos de gerenciamento.84 CONCLUSÃO Desde o surgimento das redes de computadores seu grau de complexidade e abrangência aumentou exponencialmente. Sobre o uso do SNMP com o CLP demonstrou que será de grande importância para a indústria diminuir custos. isso não foi possível de se realizar por diversas razões de ordem técnica e de tempo. o baseado no protocolo SNMP. Com o projeto FreeNMS funcionando plenamente. procurou-se mostrar alguns estudos que foram feitos utilizando estes protocolos: projeto com CLP e FreeNMS. otimizar os seus processos e assim. vendas. usando pouco mão-de-obra humana e isso garante um menor custo-benefício para as grandes empresas que utilizam essas aplicações. 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. Entretanto. 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. No início do estudo sobre esse assunto. Já através do projeto FreeNMS. . cadastros. foi feito um estudo criterioso sobre as funcionalidades dos protocolos SNMP e RMON. Para isso. a gestão prática deste não está sendo amplamente utilizada pelos profissionais da área de informática. não se tinha idéia do seria esses protocolos e desejava-se realizar alguma experiência prática.

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->