IMPLEMENTAÇÃO DO MIB BROWSER E DO MÓDULO CENTRAL DE UMA PLATAFORMA DE GERÊNCIA DE REDES

CURSO DE INFORMÁTICA

(BACHARELADO)

IMPLEMENTAÇÃO DO MIB BROWSER E DO MÓDULO CENTRAL

DE UMA PLATAFORMA DE GERÊNCIA DE REDES

LUCIANO COELHO

(BACHARELADO)

IMPLEMENTAÇÃO DO MIB BROWSER E DO MÓDULO CENTRAL

DE UMA PLATAFORMA DE GERÊNCIA DE REDES

Relatório do Trabalho de Conclusão de

Curso submetido à Universidade do

Planalto Catarinense para obtenção dos

créditos

de

disciplina

com

nome

equivalente no curso de Informática -

Bacharelado.

LUCIANO COELHO

Orientador: Prof. Ricardo Alexandre

Reinaldo de Moraes, M.Sc.

Co-Orientadora: Profª. Analúcia Schiaffino

Morales De Franceschi, Dra.

IMPLEMENTAÇÃO DO MIB BROWSER E DO MÓDULO CENTRAL DE

UMA PLATAFORMA DE GERÊNCIA DE REDES

LUCIANO COELHO

ESTE RELATÓRIO, DO TRABALHO DE CONCLUSÃO DE CURSO, FOI

JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS DA

DISCIPLINA DE TRABALHO DE CONCLUSÃO DE CURSO DO VIII

SEMESTRE, OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:

BACHAREL EM INFORMÁTICA

Prof. Ricardo Alexandre Reinaldo de

Moraes, M.Sc.

Orientador

Profª. Analúcia Schiaffino Morales

De Franceschi, Dra.

Co-Orientadora

BANCA EXAMINADORA:

Prof. Alexandre Perin de Souza,

M.Sc.

UNIPLAC

Prof. Douglas Nazareno Debiazi Vargas,

M.Sc.

UNIPLAC

Prof. Angelo Augusto Frozza, Esp.

Supervisor de TCC

Prof. Alexandre Perin de Souza, M.Sc.

Coordenador de Curso

Dedico a Mari, minha esposa, que durante

todo o período da graduação soube

entender os momentos em que estive

ausente.

Agradeço a minha família pelo apoio

recebido e pela educação que me deram, a

meus amigos de graduação na ajuda com

os estudos, aos professores e orientadores

que tornaram a conclusão deste trabalho

possível, e em especial a Deus.

LISTA DE ILUSTRAÇÕES ... VIII

LISTA DE SIGLAS ... IX

RESUMO ... X

ABSTRACT ... XI

1

I

NTRODUÇÃO

... 1

1.1 Apresentação ... 1

1.2 Descrição do problema ... 3

1.3 Justificativa ... 4

1.4 Objetivo geral ... 5

1.5 Objetivos específicos ... 5

1.6 Metodologia ... 5

2

G

ERÊNCIA DE REDES

... 7

2.1 Conceitos básicos ... 7

2.2 Protocolos ... 11

2.3 SNMP ... 12

2.4 Conjunto de operações do SNMP... 13

2.4.1 Get ... 13

2.4.2 Get-next ... 14

2.4.3 Get-bulk ... 14

2.4.4 Set ... 15

2.4.5 Traps ... 15

2.4.6 Notificação ... 15

2.4.7 Inform ... 16

2.4.8 Report ... 16

2.5 Funcionamento do SNMP ... 16

2.5.1 Estrutura de informações de gerenciamento ... 18

2.5.2 Comunidades de SNMP ... 23

2.6 MIB-II ... 23

2.7 RFCs ... 26

2.8 Conclusão ... 26

3

M

ODELAGEM DO SISTEMA

... 27

3.2 Análise: especificação de requisitos ... 28

3.2.1 Descrição textual para o use-case: Efetuar Operação GET ... 29

3.2.2 Descrição textual para o use-case: Efetuar Operação SET ... 30

3.2.3 Descrição textual para o use-case: Efetuar Operação GET <> MIB-II ... 32

3.2.4 Descrição textual para o use-case: Iniciar Leitura em Grupo ... 33

3.2.5 Descrição textual para o use-case: Iniciar Novo Processo ... 34

3.3 Projeto ... 36

3.3.1 Modelagem do banco de dados ... 36

3.3.2 Descrição do funcionamento do banco de dados ... 37

3.3.3 Linguagem de programação ... 38

3.3.4 Definição das classes do Mib Browser e do módulo central da plataforma ... 40

3.4 Conclusão ... 41

4

D

ESENVOLVIMENTO

... 42

4.1 MIB Browser ... 42

4.1.1 Árvore MIB ... 44

4.2 Módulo central ... 47

4.3 Conclusão ... 50

5

C

ONSIDERAÇÕES FINAIS

... 52

REFERÊNCIAS BIBLIOGRÁFICAS ... 55

BIBLIOGRAFIA COMPLEMENTAR ... 56

APÊNDICES ... 57

FIGURA 2.1 - Estrutura de comunicação entre Gerente e Agente ...

18

FIGURA 2.2 - Árvore de objetos da SMI ...

21

FIGURA 3.1 - Especificação de requisitos através de use-case ...

29

FIGURA 3.2 - Diagrama Entidade-Relacionamento ...

36

FIGURA 3.3 - Funcionamento da linguagem Java ...

39

FIGURA 3.4 - Interação entre as classes Java ...

41

FIGURA 4.1 - MIB Browser ...

43

FIGURA 4.2 - Fragmento do código “ArvoreMib2.class” ...

44

FIGURA 4.3 - Fragmento do código “OperacoesSNMP.class” ...

45

FIGURA 4.4 - Fragmento do código “OperacoesComuns.class” ...

46

FIGURA 4.5 - Opção de leitura em grupo ...

47

FIGURA 4.6 - Módulo central ...

49

FIGURA 4.7 - Fragmento do código “OperacoesBD.class” ...

50

ASN.1

- Abstract Syntax Notation One

BER

- Basic Encoding Rules

CMOT

- Common Management Over TCP/IP

CMIP

- Common Management Information Protocol

FCAPS

- Fault, Configuration, Accounting, Performance, Security

GPL

- General Public License

IETF

- Internet Engineering Task Force

IP

- Internet Protocol

ISO

- International Standardization Organization

JIT

- Just In Time Compiler

JSDK

- Java Software Development Kit

JVM

- Java Virtual Machine

LAN

- Local Area Network

MIB

- Management Information Base

NMS

- Network Management Stations

OID

- Object Identifier

OSI

- Open Systems Interconnection

PDU

- Protocol Data Units

PHP

- Hypertext Preprocessor

RFC

- Request for Comments

SGMP

- Simple Gateway Management Protocol

SMI

- Structure of Management Information

SNMP

- Simple Network Management Protocol

SNMPv2

- Simple Network Management Protocol Version 2

SNMPv3

- Simple Network Management Protocol Version 3

TCP

- Transmission Control Protocol

TCP/IP

- Transmission Control Protocol/Internet Protocol

UDP

- User Datagram Protocol

O

MIB Browser é um dos aplicativos necessários em uma plataforma de gerência

de redes. Este aplicativo destina-se a oferecer uma interface ao administrador da

rede, onde ele possa realizar as operações de leitura e escrita dos objetos da MIB

(Management Information Base). Estas operações são realizadas através do

protocolo SNMP (Simple Network Management Protocol). Outro importante

aplicativo em uma plataforma de gerência de redes é o módulo central, que realiza

coletas periódicas e o armazenamento em banco de dados de acordo com as

configurações do administrador de redes. O presente trabalho apresenta o

desenvolvimento do MIB Browser e do módulo central de uma plataforma para

gerência de redes utilizando a linguagem Java. São abordados os objetivos,

funcionalidades e os passos seguidos para a implementação destes módulos. Os

módulos fazem parte da plataforma para gerência de redes, que está sendo

desenvolvida pelo grupo de pesquisa em redes de computadores e sistemas

distribuídos da Universidade do Planalto Catarinense - UNIPLAC, em Lages, SC

.

MIB Browser is a necessary application for a network management plataform. It is

destined to offer a interface for network manager, where he may realize read and

write operations of MIB objetcts (Management Information Base). This operations

are realized by SNMP protocol (Simple Network Management Protocol). Another

important application in a network management plataform is the main module, that

realize periodic collections and storage in a database, in agreement of network

manager. The current work present the MIB Browser and main module of a

network management plataform development using Java language. It boarded

objectives, functionalities and implementation steps of these modules. The modules

make part of network management plataform, that is being developed for the

computer networks and distributed systems research group of Universidade do

Planalto Catarinense - UNIPLAC, in Lages, SC.

1.1 Apresentação

Uma plataforma para gerência de redes é uma coleção de ferramentas

integradas para a monitoração e o controle da rede. Este sistema oferece uma interface

única, com informações sobre a rede e pode oferecer, também, um conjunto poderoso

e amigável de comandos que são usados para executar quase todas as tarefas de

gerência da rede.

A arquitetura geral de uma plataforma de gerência de redes apresenta quatro

componentes básicos: elementos de gerência, estações de gerência, protocolos de

gerência e informações de gerência (LOPES, SAUVÉ e NICOLLETTI, 2003):

 Elementos gerenciados possuem um software especial chamado

agente. Este software permite que o equipamento seja monitorado e

controlado através de uma ou mais estações de gerência. Pode-se ter

agentes instalados em dispositivos como, roteadores, comutadores,

repetidores, impressoras etc.

 Um sistema de gerência deve conter pelo menos uma estação de

gerência. Gerente é o software da estação de gerência que conversa

diretamente com os agentes nos elementos gerenciados, seja com o

objetivo de monitorá-los, seja com o objetivo de controlá-los.

 Para que a troca de informações entre gerente e agentes seja possível é

necessário que eles falem o mesmo idioma. O idioma que eles falam é

o protocolo de gerência, o qual permite operações de monitoramento

(leitura) e controle (escrita). Atualmente um dos protocolos mais

utilizados para gerência é o protocolo SNMP.

 Gerentes e agentes podem trocar informações, mas não qualquer tipo

de informação. As informações de gerência definem os dados que

podem ser referenciados em operações do protocolo de gerência, isto

é, dados sobre os quais gerente e agente conversam.

A maioria dos sistemas de gerência disponíveis no mercado são sistemas

passivos, não executam nenhum tipo de tomada de decisões, aguardando que o

administrador da rede solucione o problema. A grande maioria tem custo elevado e

não permite a completa adaptação às necessidades específicas das empresas onde eles

estão implantados (DE FRANCESCHI, 2003).

Características como heterogeneidade (plataformas de hardware e software

distintas), complexidade (tecnologia), dinamismo e a natureza distribuída, dificultam o

gerenciamento das redes de dados, principalmente, a implantação de um

gerenciamento automatizado. A heterogeneidade e a distribuição de objetos vêm sendo

contornadas através das aplicações desenvolvidas em linguagem Java, que independem

de plataforma. No entanto, o uso destas novas ferramentas não é o suficiente para

alcançar a automatização do processo. Pois, existe ainda a complexidade e o

dinamismo dos sistemas, que não são solucionados através de ferramentas comuns

(DE FRANCESCHI, 2003).

Com a evolução das redes de computadores e o aumento do número de

máquinas interconectadas, torna-se necessário o desenvolvimento de ferramentas que

auxiliem na gerência e na manutenção destas redes. Atualmente, um dos protocolos

mais utilizados neste processo é o protocolo SNMP (Simple Network Management

Protocol). O SNMP permite que sejam realizadas consultas a agentes instalados em

equipamentos da rede, que monitoram e fornecem informações a respeito do próprio

equipamento, como taxa de utilização, temperatura interna, taxa de erros, entre outros.

Os dados fornecidos pelo agente são armazenados em uma base de dados chamada

MIB (Managenent Information Base).

ferramentas que facilitam a gerência e a manutenção das redes. Estas plataformas

utilizam o protocolo SNMP para trocar as informações entre gerentes, agentes e

objetos gerenciados.

Este trabalho faz parte do Projeto do Grupo de Pesquisa em Redes de

Computadores e Sistemas Distribuídos da UNIPLAC, que tem como objetivo

desenvolver uma plataforma para gerência de redes constituída por diversos módulos.

O módulo central realiza coletas periódicas das informações dos equipamentos

gerenciáveis, armazenando-os em uma base de dados; o módulo de desempenho utiliza

os dados fornecidos pelo módulo central para fornecer mecanismos que permitam

avaliar o desempenho da rede (através de gráficos e de relatórios) e o desenvolvimento

de uma estrutura para criação de agentes que empregam a metodologia desenvolvida

por MORAES e DE FRANCESCHI (2003).

Na seqüência deste capítulo serão apresentados a descrição do problema, a

justificativa, os objetivos e a metodologia utilizada no desenvolvimento do trabalho.

No capítulo 2 é apresentado a gerência de redes e os principais protocolos utilizados, o

funcionamento do protocolo SNMP, abordando os tipos de dados para os objetos,

operações suportadas e todo o seu funcionamento e estrutura, tambem são detalhados.

No capítulo 3 é apresentada a modelagem do sistema e do banco de dados, e ainda, a

definição da linguagem de programação utilizada e a definição das classes que foram

implementadas. Na seqüência, o capítulo 4 apresenta o desenvolvimento do MIB

Browser e do módulo central da plataforma. No capítulo 5 serão apresentadas as

considerações finais e, por fim, as referências bibliográficas.

1.2 Descrição do problema

As redes vêm se tornando muito comuns no dia-a-dia. Como exemplos,

pode-se observar os serviços dos bancos que podem ser acessados a qualquer horário

de casa ou de um terminal 24 horas e as compras com cartões de crédito, que podem

ser aprovadas imediatamente. Além disso, é possível sentar à frente de um computador

pessoal e viajar através da Internet para qualquer lugar no mundo, acessando uma

vasta quantidade de informações. No entanto, para o oferecimento destes serviços há a

necessidade de uma estrutura de rede. No caso de indisponibilidade de serviços

oferecidos em uma rede, importantes negócios podem ser perdidos, ocasionando, por

exemplo, perdas monetárias. Gerência de redes é o processo que envolve a

monitoração e o controle dos equipamentos, dos serviços e dos usuários que compõem

uma rede de computadores. A tarefa de gerência é difícil devido a sua complexidade e

distribuição das informações. No sentido de minimizar esta tarefa é essencial que as

empresas possuam uma plataforma para gerência de redes personalizada com as suas

necessidades específicas. Os sistemas de gerência disponíveis no mercado são

ferramentas que auxiliam o processo de monitoração, fornecem relatórios e emitem

alarmes após alguma falha ser detectada. São sistemas passivos, não executam nenhum

tipo de tomada de decisão aguardando que o administrador da rede solucione o

problema (DE FRANCESCHI, 2003). A maioria dos sistemas de gerência de redes

possuem um custo elevado e os administradores de redes desconhecem os benefícios

do processo de gerência.

1.3 Justificativa

Atualmente, no cenário regional, observa-se o crescimento de sistemas

integrados através de redes de computadores. Esta integração pode ocorrer através de

um serviço dedicado ou utilizando um provedor de serviços. O serviço dedicado

normalmente é utilizado por empresas de médio e grande porte. Enquanto que a

integração através de um provedor faz parte da realidade de empresas menores. Em

ambos os casos, são necessárias atividades de gerência de redes. No entanto, as

ferramentas para gerência de serviço da rede possuem um custo elevado.

Neste contexto, o presente trabalho faz parte do projeto: “Desenvolvimento

de uma plataforma de gerência de redes”, integrado ao grupo de pesquisa em Redes de

Computadores e Sistemas Distribuídos da UNIPLAC. O objetivo do projeto é permitir

que pequenas e médias empresas da região possam implantar mecanismos de gerência

em suas redes, através do uso da plataforma que está sendo desenvolvida, a qual será

distribuída sob a licença GPL (General Public License).

1.4 Objetivo geral

Especificamente neste trabalho de conclusão de curso, o objetivo geral é o

desenvolvimento do módulo central e do MIB Browser da plataforma de gerência de

redes.

1.5 Objetivos específicos

Para atingir o objetivo geral, os seguintes objetivos específicos são necessários:

a) Pesquisar os mecanismos e as plataformas para gerência de redes;

b) Definir a linguagem de programação que será utilizada na implementação;

c) Pesquisar o funcionamento do protocolo SNMP;

d) Selecionar um pacote SNMP para ser utilizado na implementação;

e) Pesquisar RFCs (Request for Comments) referentes à gerência de redes;

f) Identificar as funções de gerência necessárias na implementação dos

módulos e realizar a modelagem dos dados;

g) Implementar o módulo central da plataforma;

h) Implementar o MIB Browser;

i) Validar os módulos implementados.

1.6 Metodologia

Na primeira etapa do trabalho foi realizada uma revisão bibliográfica, com o

objetivo de estabelecer um referencial teórico. Este levantamento foi realizado através

de pesquisas em livros, artigos, revistas e Internet. Através deste estudo procurou-se

definir a linguagem de programação e alguns requisitos para o desenvolvimento do

módulo central e do MIB Browser. Na segunda etapa realizou-se a modelagem do

MIB Browser e do módulo central. A modelagem foi realizada a partir de entrevistas

informais com administradores de redes e com os membros do grupo de pesquisa em

redes e sistemas distribuídos. A partir destas entrevistas foram definidos os requisitos

funcionais dos módulos. Em seguida foram realizadas as respectivas implementações,

que foram divididas em classes e package. Após a implementação, foram realizados

testes de usabilidade, onde foram validados os módulos implementados.

Neste capítulo são apresentados os conceitos sobre gerência de redes de

computadores, descrevendo o gerenciamento de redes baseado no protocolo SNMP

(Simple Network Management Protocol).

2.1 Conceitos básicos

As redes de computadores foram concebidas, inicialmente, como um meio de

compartilhar dispositivos periféricos mais caros como impressoras, modens de alta

velocidade etc. Entretanto, à medida que as redes crescem e tornam-se integradas às

organizações, o compartilhamento dos dispositivos toma aspecto secundário em

comparação às outras vantagens oferecidas. As redes passaram a fazer parte do

cotidiano dos usuários como uma ferramenta que oferece recursos e serviços que

permitem a integração e o aumento de produtividade (SZTAJNBERG, 2003).

Provavelmente, qualquer um dos leitores já tenha tido contato com algum

tipo de falha durante uma operação em uma rede qualquer. As redes, portanto, são

equipamentos que operam de forma distribuída e estão sujeitos a diversos tipos de

falhas: falhas nos equipamentos devido a ação do tempo, como umidade e calor

excessivo; falhas operacionais ou de uso indevido dos equipamentos; falha de

sobrecarga etc. Considerando este quadro, torna-se cada vez mais necessário a

gerência das redes de computadores para manter todo este ambiente funcionando de

forma adequada (DE FRANCESCHI, 2003).

Gerência de redes é o processo que envolve a monitoração e o controle dos

equipamentos, serviços e usuários que compõem uma rede de computadores (LOPES,

SAUVÉ e NICOLLETTI, 2003).

A gerência de redes está associada ao controle de atividades e ao

monitoramento do uso de recursos da rede. As tarefas básicas da gerência em redes

são: obter informações da rede; tratar estas informações de maneira à possibilitar um

diagnóstico; e encaminhar as soluções dos problemas. Para cumprir estes objetivos,

funções de gerência devem ser embutidas nos diversos componentes de uma rede,

possibilitando descobrir, prever e reagir a problemas. Além disso, foram padronizados

três modelos para resolver os problemas associados à gerência em redes do modelo de

referência OSI (Open Systems Interconection): modelo organizacional, modelo

informacional e modelo funcional (SZTAJNBERG, 2003):

 Modelo organizacional estabelece a hierarquia entre sistemas de

gerência em um domínio de gerência, dividindo o ambiente a ser

gerenciado em vários domínios.

 Modelo informacional define os objetos de gerência, as relações e as

operações sobre esses objetos. Uma MIB é necessária para armazenar

os objetos gerenciados.

 Modelo funcional descreve as funcionalidades de gerência: gerência

de falhas, gerência de configuração, gerência de desempenho,

gerência de contabilidade e gerência de segurança.

Existe um conjunto de conceitos e definições que são úteis para o

entendimento geral do conceito de gerência de redes que são apresentados a seguir

(MEIRELLES, 1999):

 Ambiente gerenciado compreende mecanismos com suporte a

funcionalidades de gerenciamento, juntamente com os aspectos de

comunicação que permitem suas interconexões. Desta forma, o

ambiente gerenciado pode ser constituído de um ou mais mecanismos,

como exemplos, pode-se citar: um roteador, dispositivos gerenciáveis

de uma mesma sub-rede, dispositivos gerenciáveis de um conjunto de

LANs (Local Area Network) interligadas.

que apresente necessidade e condições de ser gerenciado. Como

exemplo de hardware pode-se citar: interfaces de rede, discos e

impressoras. O software poderá compreender, por exemplo, aspectos

relacionados à implementação da pilha TCP/IP (Transmission Control

Protocol/Internet Protocol), como estatísticas sobre o processamento

de datagramas IP (Internet Protocol).

 Sistema de gerenciamento de rede é formado por uma coleção de

ferramentas utilizadas no monitoramento e controle da rede. A

coleção de software de um sistema de gerenciamento de rede é

também organizada para assumir o papel de gerente, agente ou ambos.

 Gerente compreende um tipo de software que permite a obtenção e o

envio de informações de gerenciamento junto aos mecanismos

gerenciados mediante comunicação com um ou mais agentes. As

informações de gerenciamento podem ser obtidas com o uso de

requisições efetuadas pelo gerente ao agente, como também, mediante

envio automático disparado pelo agente a um determinado gerente.

Tipicamente um gerente está presente em uma estação de

gerenciamento de rede.

 Agente compreende um tipo de software presente junto aos

dispositivos gerenciados. A função principal de um agente

compreende o atendimento das requisições enviadas por um software

gerente e o envio automático de informações de gerenciamento ao

software gerente, indicando a ocorrência de um evento previamente

programado. Também compete ao agente efetuar a interface entre os

diferentes mecanismos usados na instrumentação das funcionalidades

de gerenciamento inseridos em um determinado dispositivos

gerenciado.

 Base de informações de gerenciamento é um conjunto de variáveis

usadas para representar informações estáticas ou dinâmicas vinculadas

a um determinado dispositivo gerenciado. Grande parte das

funcionalidades de um software Gerente/Agente destina-se à troca de

dados existente na base de informações de gerenciamento, conhecida

na literatura como MIB.

 Protocolo de gerenciamento compreende o conjunto de regras e

formatos de mensagens. Os mecanismos de comunicação entre

gerentes e agentes são implementados com base nas especificações de

um determinado protocolo de gerenciamento. O SNMP e o CMIP

(Common Management Information Protocol) são os usados

atualmente na indústria.

 Monitoramento é uma função de gerenciamento da rede destinada à

observação e análise do estado e comportamento dos dispositivos

gerenciados. Um usuário, ao utilizar um software gerente para

verificar o estado operacional (up ou down) de uma ou mais interfaces

de rede, está efetuando uma função de monitoramento.

 Controle é uma função de gerenciamento da rede destinada à alteração

de parâmetros de gerenciamento que acarretam ações junto aos

dispositivos gerenciados. Um usuário, ao utilizar um software gerente

para desabilitar o funcionamento temporário de uma determinada

interface de rede, está executando uma função de controle.

A gerência de redes é dividida em cinco áreas funcionais. Embora esta

classificação tenha sido desenvolvida para o modelo de referência OSI, esta forma de

organizar o gerenciamento de rede também é utilizado para o modelo Internet

(LOPES, SAUVÉ e NICOLLETTI, 2003):

 Gerenciamento de falha compreende um conjunto de facilidades que

habilitam a detecção, o isolamento e a correção de operações

anormais no ambiente de rede gerenciado.

 Gerenciamento de contabilização compreende um conjunto de

facilidades que permitem a apropriação dos custos e tarifação em

decorrência da utilização dos objetos gerenciados.

monitorar as condições do ambiente de rede, identificando e

ocasionando mudanças no estado dos objetos gerenciados.

 Gerenciamento de desempenho oferece um conjunto de funções para

medir, monitorar, avaliar e relatar os níveis de desempenho

alcançados pela rede.

 Gerenciamento de segurança trata de questões relacionadas a garantir

a política de segurança definida para rede, além de cuidar da

segurança do próprio gerenciamento.

2.2 Protocolos

Um protocolo é um conjunto de regras e convenções precisamente definidas

que possibilita a comunicação através de uma rede de computadores. As máquinas

interligadas nessa rede se comunicam trocando unidades de dados chamadas PDU

(Protocol Data Units), cujo formato e seqüência são definidos pelos protocolos de

comunicação de dados (MAURO e SCHMIDT, 2001).

Um protocolo de gerenciamento de redes especifica a comunicação entre o

programa cliente e o programa do servidor de gerenciamento e define as relações

administrativas ente os dispositivos que estão sendo gerenciados (COMER, 1998).

O modelo de referência OSI utiliza o protocolo CMIP para sua gerência.

Com a conversão da ARPANET para Internet houve a necessidade de novas

ferramentas para o gerenciamento de redes do modelo Internet. A busca, mesmo que

sem sucesso, por ferramentas para gerenciamento do modelo Internet iniciou com a

definição das RFCs 1028 e 1067. Somente em maio de 1990 é que foi publicada a

RFC 1157 que definia o protocolo SNMPv1. Paralelamente a esta RFC foi definida a

RFC 1155 que tratava das informações de gerenciamento. O SNMP acabou se

tornando um padrão para a gerência da Internet (TANENBAUM, 1997). Outra

alternativa para gerência da Internet, é o protocolo CMOT (Common Management

Over TCP/IP). O CMOT utiliza padrões de gerência OSI para o gerenciamento em

ambientes Internet.

2.3 SNMP

O SNMP é o protocolo padrão da Internet para gerenciar dispositivos em

redes de IP. Diversos dispositivos aceitam o SNMP, incluindo os roteadores, switches,

servidores, estações de trabalho, impressoras, suporte de modem, UPS

(Uninterruptible Power Supplies/no-breakes) etc. As informações que se pode

monitorar com este protocolo variam de itens relativamente simples e padronizados,

como o volume de tráfego fluindo para ou de uma interface, até itens mais complexos

de hardware de fornecedores específicos, por exemplo, a temperatura do ar dentro de

um roteador (MAURO e SCHMIDT, 2001).

O SNMP oferece aos usuários um conjunto de operações que permitem o

gerenciamento remoto dos dispositivos da rede, ou seja, em vez de definir um grande

número de comandos, lança as operações em um paradigma de busca e

armazenamento (tefch-store paradigm), desta forma o SNMP tem basicamente dois

comandos: leitura e escrita (MAURO e SCHMIDT, 2001). Com este recurso o SNMP

ganha em estabilidade, simplicidade e flexibilidade. Este conjunto simples de

operações permite ao administrador modificar ou verificar o estado de dispositivos

baseados. Por exemplo, é possível utilizar o SNMP para encerrar uma interface em um

roteador ou verificar a velocidade operacional de uma interface de Ethernet (COMER,

1998).

Embora o SNMP seja normalmente associado ao gerenciamento de

roteadores, é importante saber que ele pode ser utilizado para gerenciar vários tipos de

dispositivos. Esta impressão vem do fato de seu antecessor, o SGMP (Simple Gateway

Management Protocol), ter sido desenvolvido para gerenciar roteadores da Internet. É

possível utilizar o SNMP para gerenciar sistemas Unix, Windows, impressoras, racks

de modem, fontes de energia etc. É possível gerenciar qualquer dispositivo executando

um software que permita a recuperação de informações de SNMP (MAURO e

SCHMIDT, 2001).

2.4 Conjunto de operações do SNMP

Nesta seção é mostrado o funcionamento efetivo do protocolo SNMP.

De acordo com MAURO e SCHMIDT (2001), PDU é o formato de

mensagem que os gerenciadores e agentes utilizam para enviar e receber informações.

Existe um formato PDU padrão para cada uma das seguintes operações SNMP:

 get

 get-next

 get-bulk (SNMPv2 e SNMPv3)

 set

 get-response

 trap

 notification (SNMPv2 e SNMPv3)

 inform (SNMPv2 e SNMPv3)

 report (SNMPv2 e SNMPv3)

A seguir cada uma destas operações são descritas.

2.4.1 Get

A solicitação de get é iniciada pelo gerenciador, que a envia para o agente. O

agente recebe a solicitação e a processa para obter o máximo proveito. Pode ocorrer de

o dispositivo estar com carga excessiva, e não conseguir responder à solicitação,

ocorrendo então a exclusão da solicitação. Se o agente conseguir obter as informações

solicitadas, retornará um get-response para o gerenciador, que recebe estes dados e os

processa (MAURO e SCHMIDT, 2001).

A solicitação get, possui uma vinculação de variáveis, ou varbind, que é uma

lista de objetos da MIB. Isto permite que o receptor de uma solicitação veja o que o

emissor deseja saber. As vinculações de variáveis podem ser consideradas como os

pares OID (Object Identifier) = valor que facilitam para o emissor selecionar as

informações necessárias quando o receptor preencher a solicitação e retornar à

resposta. Para uma operação de get são necessários três argumentos: o nome do

dispositivo ou seu endereço IP, a string de comunidade e a OID (MAURO e

SCHMIDT, 2001).

Quando informa-se valores de OIDs, sempre deve-se acrescentar um número

no fim do OID. No SNMP, os objetos da MIB são definidos pela convenção x, y, onde

x é a verdadeira OID do objeto gerenciado e y é o identificador de instância. Para os

objetos escalares (isto é, os objetos não definidos como uma linha em uma tabela) y

sempre será 0. No caso de uma tabela, o identificador da instância permite selecionar

uma linha específica da tabela (MAURO e SCHMIDT, 2001).

O comando get serve para recuperar um único objeto da MIB de cada vez.

2.4.2 Get-next

A operação de get-next permite emitir uma seqüência de comando para

recuperar um grupo de valores de uma MIB.

O comando get-next atravessa uma subárvore em ordem lexicográfica. Como

uma OID é uma seqüência de inteiros, é fácil para um agente iniciar na raiz da árvore

de objetos da respectiva SMI (Structure of Management Information) e descer até

encontrar a OID que está procurando. Quando o gerenciador receber uma resposta do

agente ao comando get-next recém emitido, ela enviará outro comando get-next e

continuará repetindo esse comando até que o agente retorne um erro, significando que

o final da MIB foi alcançado e não há mais objetos a serem obtidos (MAURO e

SCHMIDT, 2001).

2.4.3 Get-bulk

Esta operação esta disponível no SNMPv2, ela permite que um aplicativo de

gerenciamento recupere uma grande seção de uma tabela, de uma só vez. A operação

do get padrão pode tentar recuperar mais de um objeto MIB de uma vez, mas os

tamanhos de mensagens são limitados pelos recursos do agente. Get-bulk, por outro

lado, instrui o agente a retornar o máximo da resposta possível. Isso significa que são

possíveis respostas incompletas. Ao emitir um comando get-bulk, é necessário definir

dois campos: nonrepeaters e max-repetitions. O campo nonrepeaters informa ao

comando get-bulk que é possível recuperar os primeiros n objetos com uma simples

operação de get-next. O campo max-repetitions instrui o comando get-bulk a tentar até

n operações get-next para recuperar os demais objetos (MAURO e SCHMIDT, 2001).

2.4.4 Set

O comando set é utilizado para modificar o valor de um objeto gerenciado ou

para criar uma nova linha em uma tabela. Os objetos definidos na MIB como

read-write ou read-write-only podem ser alterados ou criados com esse comando. Um

gerenciador pode definir mais de um objeto de cada vez (MAURO e SCHMIDT,

2001).

2.4.5 Traps

Uma trap é um meio de um agente informar ao gerenciador que aconteceu

algo errado. A trap se origina no agente e é enviada para o destino configurado no

próprio agente. Geralmente, o destino da trap é o endereço IP do gerenciador.

Nenhuma confirmação é enviada do gerenciador para o agente, de modo que o agente

não sabe se a trap alcançou o gerenciador. Como o SNMP usa o UDP (User Datagram

Protocol) e as traps são elaboradas para informar os problemas ocorridos na rede, as

traps estão propensas principalmente à perda e a não alcançar seus destinos.

Entretanto, o fato de que as traps podem desaparecer não as torna menos

úteis; em um ambiente bem planejado, elas fazem parte do gerenciamento da rede. As

traps podem disparar mensagens, como por exemplo: linkDown se o canal de

comunicação estiver inativo e linkUp se o canal de comunicação estiver ativo

(MAURO e SCHMIDT, 2001).

2.4.6 Notificação

SNMPv2 define um TYPE. O formato PDU para o

NOTIFICATION-TYPE é idêntico ao do get e set (MAURO e SCHMIDT, 2001).

2.4.7 Inform

O SNMPv2 fornece um mecanismo inform, que permite a comunicação entre

gerenciadores. Essa operação pode ser útil quando for necessário mais de um

gerenciador na rede. Quando um inform é enviado de um gerenciador para outro, o

receptor envia uma resposta para o emissor confirmando o recebimento do evento.

Esse comportamento é semelhante aos das solicitações de get e set (MAURO e

SCHMIDT, 2001).

2.4.8 Report

A operação de report foi definida na versão draft do SNMPv2, mas nunca foi

implementada. Agora, faz parte da especificação do SNMPv3 e deve permitir a

comunicação entre os mecanismos do SNMP (MAURO e SCHMIDT, 2001).

2.5 Funcionamento do SNMP

Utilizando o protocolo SNMP, um gerente pode controlar muitos agentes. O

protocolo é construído sobre o UDP, que é o protocolo de transporte não orientado a

conexão. A informação é armazenada em PDUs do SNMP codificadas de acordo com

a linguagem ASN.1 (Abstract Syntax Notation One) diretamente sobre o protocolo de

transporte.

Como o SNMP utiliza um serviço de transporte não confiável, as operações

entre gerente e agente são realizadas sem confirmação. Portanto, deve-se ter certeza

que a mensagem chegou ao destinatário através de um reconhecimento. Se o

reconhecimento não chega durante um certo período (time-out) a mensagem deve ser

retransmitida.

Desde a publicação original do SNMP várias propostas de melhora foram

apresentadas. Em 1992, o grupo de pesquisa resolveu acatar algumas dessas propostas

e produzir um novo padrão. Entre estas melhorias destacam-se: maior segurança, a

possibilidade de construir uma hierarquia de gerentes e uma nova primitiva que

permite a operação de resgate de um grupo de informações.

O SNMP usa a porta 161 do UDP para enviar e receber solicitações e a porta

162 para receber traps de dispositivos gerenciados. Todo dispositivo que implementa o

SNMP deve utilizar esses números de porta como defaults, mas alguns fornecedores

permitem modificar as portas defaults na configuração do agente. Se as portas forem

modificadas, o gerenciador deve ser informado sobre essas alterações para consultar o

dispositivo por meio das portas corretas (MAURO e SCHMIDT, 2001).

Segundo TANENBAUM (1997), o protocolo SNMP é dividido em quatro

componentes:

 Nó gerenciado é qualquer dispositivo que possua um agente SNMP;

 Estação de gerenciamento pode ser um computador comum que

executa um software especial e que possue processos que se

comunicam com os agentes distribuídos na rede enviando comandos e

obtendo respostas;

 Informações de gerenciamento é o conjunto de objetos que cada

dispositivo possui, é também chamado de MIB;

 Protocolo de gerenciamento permite que a estação de gerenciamento

interaja com os agentes, realizando a leitura/escrita dos objetos da

MIB.

Para MAURO e SCHMIDT (2001), no mundo do SNMP, existem dois tipos

de entidades: gerenciadores e agentes. Um gerenciador é um servidor executando

algum tipo de sistema de software que pode lidar com tarefas de gerenciamento de

uma rede. Os gerenciadores costumam ser chamados NMS (Network Management

Stations). Um gerenciador é responsável pela operação de polling e por receber traps

de agentes de rede.

Uma poll é a operação de consultar informações em um agente (roteador,

comutador, servidor Unix etc). Essas informações podem ser utilizadas posteriormente

para detectar se ocorreu algum tipo de evento desastroso. Uma trap é um método

utilizado por um agente para informar o gerenciador que algo aconteceu. As traps

enviadas de modo assíncrono, não em resposta a consultas do gerenciador. Além disso,

o gerenciador é responsável por executar uma ação baseada nas informações recebidas

do agente.

A entidade agente é a peça de software executada nos dispositivos da rede

gerenciados pelo usuário. A Figura 2.1 mostra a estrutura da comunicação entre

gerente e agente. O agente pode ser um programa separado ou pode ser incorporado ao

sistema operacional. Atualmente, a maioria dos dispositivos de IP é fornecida com

alguma modalidade de agente de SNMP interno. O fato dos fornecedores desejarem

implementar agentes em alguns de seus produtos facilita ainda mais o serviço do

administrador de sistema ou do gerente da rede.

Figura 2.1 - Estrutura de comunicação entre Gerente e Agente

Fonte: (RAMOS, 2001)

É importante lembrar que as polls e traps podem acontecer simultaneamente.

Não há restrições sobre quando o gerenciador pode consultar o agente nem sobre

quando um agente pode enviar uma trap.

Além dos gerenciadores e agentes, há outros elementos essenciais em um

sistema de gerência, destacando-se: a base de dados (MIB), que é uma coleção de

objetos gerenciáveis mantida pelos agentes; autenticação, que é o meio de segurança

pelo qual o agente SNMP valida as requisições de uma estação de gerência antes de

respondê-las.

2.5.1 Estrutura de informações de gerenciamento

objetos gerenciados e os respectivos comportamentos. Um agente possui uma lista dos

objetos por ele rastreados. Esse tipo de objeto é o status operacional de uma interface

de roteador (por exemplo, em funcionamento, parada ou em teste). Esta lista define

coletivamente as informações que o gerenciador pode utilizar para detectar o

funcionamento geral do dispositivo em que o agente reside (MAURO e SCHMIDT,

2001).

De acordo com MAURO e SCHMIDT (2001), a SMIv1, RFC 1155 define

com exatidão como os objetos gerenciados são nomeados e especifica os respectivos

tipos de dados associados. A SMI versão 2 (SMIv2, RFC 2578) fornece otimizações

para o SNMPv2.

Os objetos gerenciados são definidos da seguinte forma:

 O nome ou identificador de objeto (OID – Object Identifier) define

com exclusividade um objeto gerenciado. Geralmente, os nomes são

exibidos em dois formatos: numérico e em formato de uma string.

 O tipo de dado ou sintaxe de um objeto gerenciado é definido por

meio de um subconjunto de ASN.1. A ASN.1 é um meio de

especificar o modo como os dados são representados e transmitidos

entre gerenciadores e agentes, no contexto do SNMP. A vantagem em

relação à ASN.1 é o fato de que a notação independe de máquina.

 Uma única instância de um objeto gerenciado é codificada em uma

string de octetos por meio do método BER (Basic Encoding Rules). O

método BER define o modo de codificação e decodificação dos

objetos para que sejam transmitidos através de um meio de transporte,

como a Ethernet.

2.5.1.1 Nomeando OIDs

Os objetos gerenciados são organizados em forma de árvore hierárquica.

Essa estrutura é base do esquema de atribuição de nomes dos objetos SNMP,

garantindo que seus nomes sejam únicos e absolutos. Um OID de objeto é a seqüência

de rótulos numéricos do nó raiz até o nó do objeto desejado. A seqüência é escrita

usando-se pontos para separar os níveis da árvore. A cada nome de variável é

necessário o acréscimo de um sufixo, para variáveis que não façam parte de uma

tabela do agente o sufixo poderá ser 0, e as variáveis pertencentes a uma tabela,

receberão um sufixo corresponde por linha da tabela. O sufixo pode ser qualquer

número, desde um simples número 0 até mesmo um endereço IP completo, desta

forma não há como adivinhar qual valor numérico foi atribuído ao sufixo de um

variável. Para realizar a leitura de objetos ao qual não conhece-se o sufixo, pode ser

usada a operação get-next-request, que a partir do prefixo consegue obter o sufixo da

variável, por exemplo, se fosse enviada ao agente uma solicitação de get-next-request

informando o prefixo 1.3.6.1.2.1.3 o retorno seria 1.3.6.1.2.1.3.0 (COMER, 1998). A

figura 2.2 mostra os primeiros níveis da árvore hierárquica.

Cada objeto gerenciado possui uma OID numérica e nome em texto

associado. A notação decimal de pontos é o modo de representação interna de um

objeto gerenciado dentro de um agente; o nome em texto, como um nome de domínio

IP, evita a necessidade de memorizar strings de inteiros longas e cansativas.

Na árvore de objetos, o nó posicionado no início da árvore é denominado

raiz, tudo o que tiver filhos será uma subárvore e tudo o que não tiver filhos será

chamado de nó de folha. Por exemplo, a raiz na figura 2.2, o ponto inicial da árvore,

não tem denominação. A respectiva subárvore é formada por ccitt(0), iso(1) e joint(2).

Nessa ilustração, iso(1) é o único nó que contém um subárvore; os outros dois nós são

nós de folha, ccitt(0) e joint(2) não pertencem ao SNMP e não serão tratados neste

trabalho (MAURO e SCHMIDT, 2001).

A ramificação directory não é usada no momento. A ramificação

management, ou mgmt, define um conjunto padrão de objetos de gerenciamento da

Internet. A ramificação experimental é reservada para fins de teste e pesquisa

(MAURO e SCHMIDT, 2001).

Os objetos da ramificação private são definidos unilateralmente, o que

significa que os indivíduos e as organizações são responsáveis pela definição dos

objetos dessa ramificação.

Figura 2.2 – Árvore de objetos da SMI

2.5.1.2 Tipos de dados para os OIDs

O atributo syntax oferece definições de objetos gerenciados por meio de um

subconjunto do ASN.1. A SMIv1 define vários tipos de dados primordiais para o

gerenciamento de redes e dispositivos de rede. É importante lembrar que esses tipos de

dados são apenas um meio de definir o tipo de informação que um objeto gerenciado

pode conter. O SMIv1 suporta os seguintes tipos de dados (MAURO e SCHMIDT,

2001):

 Integer é um número de 32 bits usado para especificar tipos

numerados no contexto de um único objeto gerenciado.

 Octet String é uma string de zero ou mais octetos (bytes) geralmente

utilizada para representar strings de texto, mas usada ocasionalmente

para representar endereços físicos.

 Counter é um número de 32 bits com o valor mínimo de 0 e máximo

de 4.294.967.295. Quando o valor máximo é alcançado, volta a zero e

inicia novamente.

 Object Identifier é uma string decimal de pontos que representa um

objeto gerenciado na árvore de objetos.

 Null atualmente esta sem uso no SNMP.

 Sequence define listas que contêm zero ou mais tipos diferentes de

dados do ASN.1.

 Sequence Of define um objeto gerenciado formado por uma seqüência

de tipos do ASN.1.

 IpAddress representa um endereço do Ipv4 de 32 bits.

 NetworkAddress é idêntico ao tipo IpAddress, mas pode representar

tipos diferentes de endereços de rede.

 Gauge é um número de 32 bits com valor mínimo de 0 e máximo de

4.294.967.295. Ao contrario de um counter, um gauge pode aumentar

e diminuir aleatoriamente, mas sem ultrapassar os valores limites.

 TimeTicks é um número de 32 bits com valor mínimo de 0 e máximo

de 4.294.967.295.

 Opaque permite o armazenamento de qualquer codificação do ASN.1

em uma octet string.

O objetivo de todos esses tipos de objetos é definir objetos gerenciados.

Geralmente, as MIBs são distribuídas como arquivos de texto comuns, que podem ser

verificados (ou até mesmo modificados) com qualquer editor de texto padrão. Através

do uso deste arquivo texto, pode ser montado, por exemplo, a estrutura de árvore da

mib, utilizando esta árvore em softwares de gerência etc.

Com a definição da SMIv2 mais alguns tipos de dados foram adicionados:

 Integer32 é idêntico a Integer.

 Counter32 é idêntico a Counter.

 Gauge32 é idêntico a Gauge.

 Unsigned32 representa valores decimais no intervalo de 0 a 232 –1,

inclusive.

 Counter64 é semelhante a Counter32, mas o valor máximo é

18.446.744.073.709.551.615.

 Bits é uma lista de bits não negativos.

2.5.2 Comunidades de SNMP

O SNMPv1 e SNMPv2 usam o conceito de comunidades para definir uma

confiabilidade entre gerenciadores e agentes. Um agente é configurado com três nomes

de comunidade: read-only, read-write e trap. Os nomes de comunidades são

basicamente senhas que determinam o tipo de acesso do agente. As três strings de

comunidade controlam tipos diferentes de atividades. Como o próprio nome sugere, a

string de comunidade read-only permite ler valores de dados, sem modifica-los. Por

exemplo, essa string permite ler o número de pacotes transferidos por meio de uma

porta do roteador mas não permite redefinir os contadores. A comunidade read-write

pode ler e modificar valores de dados; com a string de comunidade read-write, é

possível ler os contadores, redefinir seus valores. Por último, a string de comunidade

trap permite receber traps (notificações assíncronas) do agente (MAURO e

SCHMIDT, 2001).

Quando é comprado um equipamento ele vêm com strings de comunidade

defaults, geralmente public para a comunidade read-only e private para a comunidade

read-write. Como a comunidade funciona como uma senha, é importante que a

comunidade para read-write seja alterada, bloqueando assim o acesso às opções de

escrita do equipamento.

2.6 MIB-II

A MIB, pode ser considerada um banco de dados de objetos gerenciados que

o agente rastreia. Todo tipo de informação sobre seu status ou estatísticas acessadas

pelo gerenciador é definida em uma MIB. Ou seja, SMI é um método para definir

objetos gerenciados, enquanto a MIB é a definição dos próprios objetos. Uma MIB

define um nome em texto de um objeto gerenciado e explica o seu significado

(MAURO e SCHMIDT, 2001).

implementam uma MIB específica denominada MIB-II, que é padronizada pela RFC

1213. Este padrão define variáveis para elementos como dados estatísticos de uma

interface (velocidades das interfaces, octetos de entrada, octetos de saída etc), assim

como alguns outros aspectos relacionados ao próprio sistema (localização e contato do

sistema etc). A MIB-II oferece um conjunto de informações padrões, porém há

situações em que é necessário outras informações adicionais às contidas na MIB-II.

Para solucionar este problema muitos fabricantes acabam desenvolvendo suas próprias

MIBs contendo os dados específicos de seus equipamentos, pode-se citar como

exemplos: ATM MIB (RFC 2515), Frame Relay DTE Interface Type MIB (RFC

2115), BGP Version 4 MIB (RFC 1657), RDBMS MIB (RFC 1697), RADIUS

Authentication Server MIB (RFC 2619), Mail Monitoring MIB (RFC 2249), DNS

Server MIB (RFC1611) (MAURO e SCHMIDT, 2001).

A MIB-II é um grupo de gerenciamento muito importante, porque cada

dispositivo com suporte a SNMP deve no mínimo aceitar a MIB-II. A MIB-II é

formada por onze subárvores, e é tida como padrão para todos os equipamentos. Ela é

definida através da RFC 1213, que determina toda a arquitetura interna da MIB-II,

definindo quais serão os seus tipos de dados, valor dos seus OIDs etc. Cada subárvore

desta tem sua ramificação de objetos (MAURO e SCHMIDT, 2001).

A MIB-II é definida como iso.org.dod.internet.mgmt.mib-2 ou 1.3.6.1.2.1. A

partir daqui, é possível ver que o grupo system é

iso.org.dod.internet.mgmt.mib-2.system ou 1.3.6.1.2.1.1 e este padrão vai ser seguido para todas as subárvores

seguintes.

A Tabela 2.1 descreve os grupos de gerenciamento definido na MIB-II.

Tabela 2.1 – Descrição resumida dos grupos da MIB-II

Subárvore

OID

Descrição

system(1)

1.3.6.1.2.1.1

Define uma lista de objetos pertencentes à operação do sistema.

Exemplos:

 SysDescr (1.3.6.1.2.1.1.1): Descrição textual da unidade.

Pode incluir o nome e a versão do hardware, sistema

operacional e o programa de rede.

 SysUpTime (1.3.6.1.2.1.1.3): Tempo decorrido (em milhares

de segundos) desde a última reinicialização do gerenciamento

do sistema na rede.

 SysContact (1.3.6.1.2.1.1.4): Texto de identificação do

gerente da máquina gerenciada e como contatá-lo.

Exemplos:

 ifNumber (1.3.6.1.2.1.2.1): Número de interfaces de rede

(não importando seu atual estado) presentes neste sistema.

 ifOperStatus (1.3.6.1.2.1.2.2.1.8): Estado atual da interface.

 ifInOctets (1.3.6.1.2.1.2.2.1.10): Número total de octetos

recebidos pela interface.

at(3)

1.3.6.1.2.1.3

O grupo address translation é fornecido somente para manter a

compatibilidade com versões anteriores e, provavelmente, será

retirado da MIB-III.

ip(4)

1.3.6.1.2.1.4

Rastreia os diversos aspectos do IP, incluindo o roteamento do IP.

Exemplos:

 ipForwarding (1.3.6.1.2.1.4.1): Indica se esta entidade é um

gateway.

 ipInReceives (1.3.6.1.2.1.4.3): Número total de datagramas

recebidos pelas interfaces, incluindo os recebidos com erro.

 ipInHdrErrors (1.3.6.1.2.1.4.4): Número de datagramas que

foram recebidos e descartados devido a erros no cabeçalho

IP.

icmp(5)

1.3.6.1.2.1.5

Rastreia aspectos como erros do ICMP. Exemplos:

 icmpInMsgs (1.3.6.1.2.1.5.1): Número total de mensagens

ICMP recebidas por esta entidade. Incluindo aquelas com

erros.

 icmpOutMsgs (1.3.6.1.2.1.5.14): Número total de mensagens

ICMP enviadas por esta entidade. Incluindo aquelas com

erros.

tcp(6)

1.3.6.1.2.1.6

Rastreia entre outros aspectos, o estado das conexões do TCP.

Exemplos:

 tcpMaxConn (1.3.6.2.1.6.4): Número máximo de conexões

TCP que esta entidade pode suportar.

 tcpCurrentEstab (1.3.6.2.1.6.9): Número de conexões TCP

que estão como estabelecidas ou à espera de fechamento.

 tcpRetransSegs (1.3.6.2.1.6.12): Número total de segmentos

retransmitidos.

udp(7)

1.3.6.1.2.1.7

Rastreia dados estatísticos do UDP. Exemplos:

 udpInDatagrams (1.3.6.1.2.1.7.1): Número total de

datagramas UDP entregues aos usuários UDP.

 udpNoPorts (1.3.6.1.2.1.7.2): Número total de datagramas

UDP recebidos para os quais não existia aplicação na

referida porta.

 udpLocalPort (1.3.6.1.2.1.7.5.1.2): Número da porta do

usuário UDP local.

egp(8)

1.3.6.1.2.1.8

Rastreia diversos dados estatísticos sobre o EGP e mantém um tabela

de vizinhos do EGP.

transmission(10)

1.3.6.1.2.1.10

Não existe atualmente objeto definido para este grupo, mas outras

MIBs específicas de mídia são definidas por meio desta subárvore.

snmp(11)

1.3.6.1.2.1.11

Avalia o desempenho da implementação básica do SNMP na

entidade gerenciada e rastreia aspectos, como o número de pacotes de

SNMP enviados e recebidos. Exemplos:

 snmpInPkts (1.3.6.1.2.1.11.1): Número total de mensagens

recebidas pela entidade SNMP.

 snmpOutPkts (1.3.6.1.2.1.11.2): Número total de mensagens

enviadas pela entidade SNMP.

 snmpInTotalReqVars (1.3.6.1.2.1.11.13): Número total de

objetos da MIB que foram resgatados pela entidade SNMP.

2.7 RFCs

De acordo com MAURO e SCHMIDT (2001), a IETF (Internet Engineering

Task Force) é responsável pela definição de protocolos padrão que controlam o tráfego

na Internet, incluindo o SNMP. A IETF publica RFCs, que são especificações para os

diversos protocolos existentes no mundo do IP. Primeiramente, os documentos se

submetem ao rastreamento de padrões como padrões sugeridos, depois passam para o

status de draft. Quando um draft final é ocasionalmente aprovado, a RFC recebe o

status de standard.

Duas outras designações de rastreamento de padrões, histórico e

experimental, definem um documento substituído por uma RFC mais recente e um

documento que ainda não está pronto para se tornar um padrão. As três versões atuais

SNMP são definidas pelas seguintes RFCs:

 SNMP Version 1 (SNMPv1) – está definida na RFC 1157 é uma

IETF com status standard.

 SNMP Version 2 (SNMPv2) – está definida na RFC 1905, RFC 1906

e RFC 1907, é uma IETF com status experimental.

 SNMP Version 3 (SNMPv3) – está definida na RFC 1905, RFC 1906,

RFC 1907, RFC 2571, RFC 2571, RFC 2572, RFC2573, RFC 2574 e

RFC 2575 é uma IETF com status sugerido, e será a próxima versão

do protocolo a alcançar o status de standard.

2.8 Conclusão

Neste capítulo foram apresentados diversos conceitos de gerência de redes.

O entendimento dos conceitos é necessário para a definição dos requisitos funcionais

do sistema a ser implementado. Destaca-se neste capítulo a descrição do protocolo

SNMP, o qual é utilizado na implementação da plataforma de gerência de redes.

Neste capítulo são apresentados os requisitos funcionais da plataforma de

gerência de redes, através de diagramas use-case

e pela modelagem do banco de

dados. Apresenta-se ainda o projeto do banco de dados, uma descrição da linguagem

de programação escolhida e das classes definidas para a implementação.

3.1 Análise: requisitos funcionais

Com base na experiência dos membros do grupo de pesquisa em redes de

computadores e sistemas distribuídos, na utilização de outras plataformas de gerência

de redes e no modelo FCAPS (Fault, Configuration, Accounting, Performance,

Security) definido pela ISO (International Standardization Organization), foram

detectados 7 (sete) requisitos principais em uma plataforma de gerência de redes, são

eles:



MIB Browser: O administrador de redes pode verificar o status de

qualquer equipamento gerenciável da rede, as diversas informações dos

equipamentos deve ser visualizada instantaneamente na tela do

computador.



Módulo central: O administrador de redes poderá selecionar qualquer

equipamento da rede, e a partir deste módulo iniciar a coleta de todas as

informações relacionadas a MIB-II (RFC-1213) do equipamento. As

informações devem ser armazenadas em um banco de dados e

administrador deve ter acesso as estas informações.



Módulo de falhas: O administrador de redes poderá visualizar gráficos e

relatórios referentes a detecção de falhas da redes, o sistema deverá gerar

alarmes automáticos de falhas da rede.



Módulo de configuração: O administrador de redes poderá configurar a

rede, a partir de uma senha de acesso especial.



Módulo de segurança: O administrador de redes poderá visualizar

relatórios referentes as tentativas de invasão ou violação de acesso da

rede, o sistema deverá gerar alarmes automáticos quando houver a

iminência de ataques na rede.



Módulo de desempenho: O administrador de redes poderá visualizar

gráficos e relatórios referentes ao desempenho da rede, o sistema deverá

gerar alarmes automáticos quando houver a iminência de degradação do

nível de desempenho da rede.



Módulo de contabilização: O administrador de redes poderá visualizar

gráficos e relatórios referentes ao uso da rede. O sistema deverá gerar

alarmes automáticos quando os limites de uso estabelecidos, forem

ultrapassados.

3.2 Análise: especificação de requisitos

Neste trabalho de conclusão de curso, estão sendo desenvolvidos o MIB

Browser e o módulo central da plataforma, portanto, serão especificados e descritos os

requisitos destes dois módulos.

A seguir será apresentada a descrição textual dos principais use-cases

mostrados na figura 3.1.

Figura 3.1 - Especificação de requisitos através de use-case

3.2.1 Descrição textual para o use-case: Efetuar Operação GET

O administrador de redes está na guia de ‘Leitura Individual’ do MIB Browser e

deseja efetuar a operação Get em um agente gerenciável. O objeto em que ele deseja

realizar esta operação está definido na MIB-II.

Seqüência típica de eventos:

1. Administrador de redes informa no campo de texto ‘IP do Agente’, o

endereço IP do agente gerenciável em que ele deseja realizar a operação

Get;

2. Administrador de redes digita no campo de password ‘Communit’, a

senha de communit do agente gerenciável;