Proposta de Gerenciamento

Universidade Federal de Santa Catarina
Departamento de Informtica e Estatstica INE

Ps-graduao em Cincia da Computao CPGCC
Administrao e Gerncia de Redes de Computadores
Mateus Casanova Pereira
Professor: Carlos Westphall
Florianpolis
2001
RESUMO..........................................................................................................................4
ABSTRACT ......................................................................................................................4
1
INTRODUO ........................................................................................................5
1.1
Motivao ................................................................................................................... 5
1.2
Gerncia de Redes de computadores........................................................................ 5
1.2.1
1.2.2
Principais Arquiteturas para Gerenciamento de Redes ................................................. 6

Protocolos de Gerenciamento............................................................................................ 6
1.3
reas Funcionais de Gerenciamento de Redes........................................................ 8
1.4
Axiomas de Gerenciamento de Redes .................................................................... 11
1.5
Concluses do Captulo ........................................................................................... 11
AMBIENTE DE GERENCIAMENTO ESCOLHIDO.........................................12

2.1
Estrutura organizacional......................................................................................... 12
2.2
Regimento ESIN/NAPI............................................................................................ 13
2.3
Recursos Humanos................................................................................................... 16
2.4
Especificao e Implementao de um Sistema de Gerenciamento .................... 16
2.4.1
Sistema de Gerenciamento de Redes .............................................................................. 16
2.4.2
Escolha do Servidor - Gerente ........................................................................................ 17
2.4.3
Sistemas Operacionais da Rede....................................................................................... 17
2.4.4
Monitoramento e Controle .............................................................................................. 18
2.4.4.1
Monitoramento de Trfego ....................................................................................... 18
2.4.4.2
Controle .................................................................................................................... 18
2.4.5
Alarmes e Acrnicos ........................................................................................................ 18
2.5
Anlise de Hardware e Software ............................................................................ 19
2.5.1
Gerente.............................................................................................................................. 24
2.5.2
Agente................................................................................................................................ 24
2.5.3
Implementando o SNMP ................................................................................................. 24
2.5.3.1
Windows NT/2000/9x .............................................................................................. 24
2.5.3.2
Linux......................................................................................................................... 26
2.5.3.3
Traps (Linux e Windows NT)................................................................................... 31
2.5.3.3.1 SNMPTRAP ....................................................................................................... 31
2.5.3.3.2 SNMPTRAPD .................................................................................................... 32
2.5.3.4
Switchs e roteadores ................................................................................................. 33
2.5.3.4.1 Traps nos Switch e Roteadores ......................................................................... 33
2.5.4
As Operaes de Traps .................................................................................................... 34
2.6
SOFTWARES DE GERENCIAMENTO ..............................................................36

3.1
Plataforma de Gerenciamento ................................................................................ 36
3.2
Softwares de Gerenciamento .................................................................................. 37
3.2.1
WhatsUP ........................................................................................................................... 39
3.2.1.1
Instalao de um servidor WEB ............................................................................... 49
3.2.2
MIB Master ...................................................................................................................... 58
3.2.3
MRTG ............................................................................................................................... 62
3.3
Arquitetura Funcional do Ambiente de Gerenciamento...................................... 63
3.4
SLA - Service Level Agreement ............................................................................64
4.1
Gerenciamento de Nvel de Servio SLM ........................................................... 64
4.2
Coexistncia entre SLA e QoS ................................................................................ 65
4.3
Abrangncia de SLAs nas Empresas...................................................................... 65
4.4
Requisitos.................................................................................................................. 66
No anexo 5 temos uma mdia das repostas dos usurios. A pesquisa foi realizada com base
na resposta de 30 usurios..................................................................................................... 69
4.5
Fundamentos para Anlise e Medio ................................................................... 70
4.5.1
Cargas de Trabalho.......................................................................................................... 70
4.5.2
Utilizao do recurso........................................................................................................ 70
4.5.3
Parmetros para Gerenciamento.................................................................................... 71
4.5.3.1
Categorizao dos Parmetros .................................................................................. 71
4.5.3.1.1 Parmetros Independentes do Servio e Tecnologia....................................... 71
4.5.3.1.2 Parmetros Dependentes da Tecnologia .......................................................... 72
4.5.3.2
Parmetros mais Comuns em Redes IP .................................................................... 72
4.5.3.2.1 Avaliao dos Parmetros Disponibilidade e Performance ........................... 73
4.5.3.2.1.1 Disponibilidade ........................................................................................... 73
4.5.3.2.1.2 Disponibilidade via SNMP......................................................................... 74
4.5.3.2.1.3 Disponibilidade via Ping Alcanabilidade ............................................. 75
4.5.3.3
Largura de Banda Utilizada ...................................................................................... 75
4.5.3.4
Erros por Interface .................................................................................................... 75
4.5.3.5
Necessidades do Mercado......................................................................................... 76
4.5.3.6
Periodicidade da Emisso dos Relatrios de SLA .................................................... 77
4.5.3.7
Aes baseadas em limites atingidos thresholds: o controle efetivo do SLA........ 78
4.5.3.8
Metodologia de Medio .......................................................................................... 78
4.5.3.8.1 Obteno dos Dados........................................................................................... 79
4.5.3.8.2 Automatizao da Coleta de Dados .................................................................. 79
4.5.3.9
Variveis monitoradas no SLA................................................................................. 79
4.5.3.9.1 Metas de Tempo de Resposta............................................................................ 87
4.5.3.9.2 Disponibilidade do Servio/Servidores (Manuteno Programada) ............. 94
4.6
Aplicao da Metodologia de Medio de Dados.................................................. 94
4.6.1
Relatrios Anlise dos Dados Coletados...................................................................... 94
4.6.1.1
Mtricas No Atingidas no SLA............................................................................... 95
4.6.1.1.1 Ambiente Napi.................................................................................................... 95
4.6.1.1.2 Ambiente POP.................................................................................................... 97
4.7
Proposta do SLA ...................................................................................................... 98
4.8
Concluses do Captulo ......................................................................................... 100
CONCLUSES E PERSPECTIVAS FUTURAS...............................................101

5.1
Concluses .............................................................................................................. 102
BIBLIOGRAFIA..................................................................................................103
ANEXOS .................................................................................................................106
RESUMO
Com a utilizao de redes de computadores em diversas organizaes e a
extenso contnua dessas, o gerenciamento de redes tornou-se indispensvel. O
gerenciamento de redes envolve o monitoramento (superviso) e o controle de recursos
distribudos em redes. Em essncia o gerenciamento de redes visa garantir uma certa
qualidade de servios a usurios de redes.
Sendo assim, este trabalho apresenta os principais conceitos e terminologias de
gerenciamento de redes, bem como uma proposta de gerenciamento com a utilizao
dos acordos de nvel de servio, SLA Service Level Agreement. O Ambiente de rede
ser constitudo, de um ambiente LAN (Local Area Network) formado pela Universidade
Catlica de Pelotas UCPel (POP UCPel e NAPI).
Outro aspecto importante do presente trabalho, foi a tentativa de utilizao de
sistemas de domnio pblico. Isto vem ao encontro com uma tendncia e esforo
mundial pela utilizao e validao deste tipo de software. Neste trabalho pode-se
observar alguns dos principais softwares condizentes com esta diretriz.
ABSTRACT
With the use of nets of computers in several organizations and the continuous
extension of those, the administration of nets became indispensable. The administration
of nets involves the monitoramento (supervision) and the control of resources
distributed in nets. In essence the administration of nets seeks to guarantee a certain
quality of services to users of nets.
Being like this, this work presents the main concepts and terminologies of
administration of nets, as well as an administration proposal with the use of the Service
Level Agreements, SLA. The net Atmosphere will be constituted, of an atmosphere
LAN (Local rea Network) formed by the Catholic University of Pelotas- UCPel (POP
UCPel and NAPI).
Another important aspect of the present work, was the attempt of use of systems
of public domain. This comes to the encounter with a tendency and world effort for the
use and validation of this software type. In this work it can be observed some of the
principal suitable softwares with this guideline.
1 INTRODUO
Neste captulo, apresenta-se uma viso geral dos principais conceitos de
gerenciamento de redes de computadores, bem como as duas principais arquiteturas de
gerenciamento de redes. O mbito deste trabalho deteve-se nas necessidades de
Gerenciamento de Nvel de Servio, mais especificamente nos Acordos de Nvel de
Servio (SLA).
Dentre os esforos existentes para um correto funcionamento das redes,
encontram-se os trabalhos desenvolvidos junto ao Internet Engineering Task Force
IETF pelo Application MIB Working Group, o qual responsvel pela definio de um
conjunto de objetos gerenciveis para o monitoramento e controle de aplicaes
distribudas. Esses objetos gerenciveis devero fornecer, especialmente, informaes
sobre a configurao, falha, desempenho, contabilizao e segurana dos elementos
gerenciados.
E so justamente as informaes coletadas destes elementos gerenciveis e que
demonstram a qualidade (ou no) dos servios de rede que passaram a ser cobrados
pelos usurios destes servios. Com a profissionalizao da prestao de servios de
rede, um Acordo de Nvel de Servio (Service Level Agreement SLA) passou a ser
definido entre o prestador dos servios de rede e o usurio da rede. Este SLA deve
garantir uma qualidade mnima constante levando-se em considerao vrios
parmetros de qualidade.
1.1
Motivao
Em decorrncia das vantagens que as redes de computadores oferecem, o nmero

e a extenso dessas esto em expanso contnua. medida que as redes crescem em
escala e extenso, dois fatores vo ficando mais evidentes: as redes, juntamente com
seus recursos e aplicaes, tornam-se cada vez mais indispensveis para as organizaes
que as utilizam, e uma maior possibilidade de ocorrerem problemas, o que pode levar as
redes a um estado de inoperncia ou a nveis inaceitveis de desempenho.
A fim de garantir uma certa qualidade dos servios a seus usurios, que as redes
de computadores devem ser gerenciadas. Este gerenciamento envolve o monitoramento
e o controle de recursos distribudos em redes. Em essncia, o gerenciamento de redes
busca assegurar que sistemas de informao, disponveis em redes, estejam operacionais
e eficazes a todo instante.
No entanto, o gerenciamento de redes de computadores por si s complexo. Na
proporo que as redes tornam-se maiores (extenso), complexas (tecnologia) e
heterogneas (plataformas de hardware e software distintas), tornam o gerenciamento
em s mais complexo ainda. Consequentemente o gerenciamento no pode ser realizado
somente pelo esforo humano. A complexidade do gerenciamento de redes impe o uso
de solues automatizadas de gerenciamento de redes.
1.2
Gerncia de Redes de computadores
As facilidades providas pelas redes tendem a estimular o crescimento das

mesmas, demandando necessidades de manuteno e planejamento futuro. Em um
ambiente com poucas mquinas conectadas em rede, uma nica pessoa capaz de
gerenci-las. Mas, considerando um ambiente onde a rede esteja distribuda entre vrias
salas, ou at mesmo prdios distintos, a manuteno torna-se onerosa consumindo
tempo e recursos. Em redes de longa distncia, a tarefa de gerenciamento

inerentemente mais complexa e indispensvel, uma vez que cobre uma rea geogrfica
extensa e envolve um grande nmero de equipamentos e usurios dependentes de seus
servios.
Alm disso tudo, com a grande utilizao e a heterogenidade das redes de
computadores, tem havido a necessidade de um esquema que oferea solues de
gerenciamento de redes coerentes e estruturadas, permitindo o monitoramento e o
controle de equipamentos compatveis ou no. Devido esta busca, dois tipos de
gerenciamento j existentes se destacam como padres, so eles OSI e TCP/IP [2].
1.2.1
Principais Arquiteturas para Gerenciamento de Redes
A exemplo do que ocorre com os demais temas da rea de redes, as diferentes

possibilidades para o gerenciamento, organizadas na forma de arquiteturas de
gerenciamento, so especificadas e propostas por organismos de padronizao.
Representado pelo CCITT (atual ITU-T), o mundo das telecomunicaes iniciou
em 1985 a definio de um sistema bsico de gerenciamento para a indstria do setor
[14]. Juntamente com a definio de um conjunto de informaes de gerenciamento, a
expresso Telecommunications Management Network - TMN, foi estabelecida para
designar a arquitetura de gerenciamento para a indstria de telecomunicaes.
Durante a dcada de 80 os principais fornecedores de equipamentos e servios
de rede, dentre eles: IBM, DEC e AT&T, tentaram impor seus padres para o
gerenciamento. Embora eficientes, dentro do escopo de produtos de cada fabricante,
uma soluo universal e padronizada tornava-se cada vez mais necessria.
A ISO, em 1989 adicionou ao modelo de referncia OSI de sete camadas, um
esquema bsico da arquitetura de gerenciamento de rede. Uma srie de documentos,
denominados como srie X.700, resultantes do trabalho cooperativo entre a ISO e o
CCITT, destina-se a criar condies para o desenvolvimento de produtos de
gerenciamento de redes de computadores e sistemas de comunicaes heterogneos.
Com a especificao do Simple Network Management Protocol - SNMP,
efetuada na sua primeira verso (SNMPv1) em 1988 pela IETF, iniciou-se o processo de
padronizao do principal modelo utilizado no gerenciamento de redes, mais
especificamente, redes que adotam a pilha de protocolos TCP/IP. Funcionalidades de
gerenciamento vem sendo cada vez mais incorporadas em diferentes dispositivos de
rede, assumindo total conformidade com a verso 1 e 2 do SNMP. No final de 1997 foi
iniciado o processo de aprovao do SNMPv3 junto a IETF. A nova verso, dentre
outros aspectos, visa ampliar as funes de gerenciamento existentes no modelo,
tratando questes de segurana [14].
1.2.2
Protocolos de Gerenciamento
Os agentes se comunicam com os gerentes atravs de um protocolo de

gerenciamento de redes a nvel de aplicaes, que utiliza a arquitetura de comunicao
da rede. Protocolos de gerenciamento de redes descrevem um formato para o envio de
informaes de gerenciamento.
Para que seja possvel a comunicao entre um gerente e um agente, necessrio
que ambos compartilhem o mesmo esquema conceitual de informaes. O gerente deve
ter, ento uma viso conceitual dos elementos gerenciados que o agente interage [21].
Informaes teis para o monitoramento de redes so coletadas e armazenadas
por agentes e disponibilizadas para um ou mais gerentes.

So utilizadas duas tcnicas para disponibilizar tais informaes: polling e event
report (relato de eventos ou notificaes).
9 Polling: uma interao do tipo pergunta reposta entre gerente e agente.
utilizada para se obter periodicamente informaes armazenadas nas MIBs
associadas aos agentes pelos gerentes.
9 Relato de Eventos: uma interao em que agentes enviam informaes a
gerentes. O gerente aguarda at que tais informaes cheguem.
Atualmente quando se fala em gerenciamento de redes, dois protocolos se
destacam:
9 SNMP: Simple Network Management Protocol.
9 CMIP: Common Management Information Service Over TCP.
Uma das diferenas fundamentais entre os dois protocolos o fato do primeiro
ser baseado no modelo de gerenciamento Internet. J o segundo baseado no modelo de
gerenciamento OSI.
Alm destas diferenas algumas outras so [3]:
9 O CMIP possui uma quantidade bem menor de produtos que o implementam;
9 O CMIP possui uma quantidade maior de operaes, permitindo uma maior
versatilidade no controle exercido sobre os elementos da rede (por exemplo,
as operaes CREATE e DELETE permitem que objetos sejam criados e
eliminados dinamicamente);
9 O CMIP mais rico, apresentando uma melhor qualidade de informao;
Uma implementao CMIP tende a ser mais lenta e maior, uma vez que
requer maior capacidade de processamento e memria.
Sabendo-se agora as diferenas bsicas entre estes dois protocolos, sabe-se que
atualmente vrios produtos tm surgido com a finalidade de gerenciar a rede, quase que
em sua totalidade baseados no padro SNMP e CMIP. O sucesso do SNMP baseia-se no
fato de ter sido ele o primeiro protocolo de gerenciamento no proprietrio, pblico,
fcil de ser implementado e que possibilita o gerenciamento efetivo de ambientes
heterogneos. Geralmente, estes produtos de gerenciamento de redes incorporam
funes grficas para o operador de centro de controle.
No gerenciamento SNMP, adicionado um componente ao hardware (ou
software) que estar sendo controlado que recebe o nome de agente. Este agente
encarregado de coletar os dados dos dispositivos e armazen-los em uma estrutura
padro. Alm desta base de dados, normalmente desenvolvido um software aplicativo
com a habilidade de sumarizar estas informaes e exibi-las nas estaes encarregadas
das tarefas de monitorar a rede.
Basicamente, so definidas quatro tipos de MIBs: MIB I, MIB II, MIB
experimental e MIB privada.
Os pioneiros na implantao dos protocolos SNMP foram os fornecedores de
gateways, bridges e roteadores. Normalmente, o fornecedor desenvolve o agente SNMP
e posteriormente desenvolve uma interface para a estao gerente da rede.
As implementaes bsicas do SNMP permitem monitorar e isolar falhas, j as
aplicaes mais sofisticadas permitem gerenciar o desempenho e a configurao da
rede. Estas aplicaes, em geral, incorporam menus e alarmes para facilitar a interao
com o profisional que est gerenciando a rede.
O esquema dos produtos desenvolvidos com o protocolo SNMP so um pouco
diferentes dos produtos que utilizam o protocolo CMIP. Os fornecedores de produtos
que utilizam o protocolo CMIP pressupem que os fabricantes possuam algum tipo de
gerenciamento em seus equipamentos, portanto estas informaes podem ser

disponibilizadas para um integrador via protocolo CMIP. O conceito de integrador foi
definido em trs nveis: o mais baixo, que contm os agentes e os elementos
gerenciadores, o intermedirio, que consiste em elementos do sistema de
gerenciamento, e finalmente o nvel mais alto, que consiste no integrador dos sistemas
de gerenciamento. Produtos como o NetView da IBM, Accumaster da AT& T, Allink da
Nynex e o SunNet Manager da Sun Microsiytems, dentre outros, so exemplos deste tipo
de implementao.
A dificuldade maior para uma aplicao integradora que os fornecedores no
tem as mesmas variveis de gerenciamento e to pouco as mesmas operaes em seus
servidores de objetos.
A escolha entre um ou outro protocolo de gerenciamento deve recair sobre o tipo
de rede e dos produtos a ela agregados, sendo que podem ser mesclados os dois
protocolos.
O SNMP e seu Internet Standard Network Management Framework so
adequados a agentes simples e fceis de implementar, enquanto o CMIP e o seu
framework Network Management Forum Release 1.0 so adequados para agentes com
um ou mais servidores de objetos dentro da modalidade cliente-servidor orientado para
objeto, dentre os quais incluem-se o RPC.
Resumindo-se poderia-se dizer que:
SNMP - Gerenciamento na famlia de protocolos TCP/IP
O protocolo SNMP apresentado como a primeira soluo para gerenciamento
de redes baseadas, inicialmente, em TCP/IP. Ser evidenciada a sua simplicidade e seus
conceitos.
CMIP - Gerenciamento no Protocolo OSI
O padro de gerenciamento proposto para o modelo OSI possui caractersticas
bastante mais robustas em relao ao SNMP. Por conta deste fato o protocolo de
gerenciamento (CMIP) e os servios oferecidos (CMIS) tambm apresentam maior
complexidade. Ilustrando esta colocao, a arquitetura de gerncia do modelo OSI
dividida em reas funcionais bem caracterizadas.
1.3
reas Funcionais de Gerenciamento de Redes
A arquitetura de gerenciamento OSI define cinco reas funcionais para prover

as necessidades do usurio no gerenciamento de suas redes:
9 Gerenciamento de Configurao;
9 Gerenciamento de Desempenho;
9 Gerenciamento de Falhas;
9 Gerenciamento de Segurana;
9 Gerenciamento de Contabilizao.
Muitas vezes as reas funcionais possuem funes de gerenciamento que se
sobrepem, isto , so utilizadas no somente em uma, mas at mesmo em vrias reas
de gerenciamento, apesar de terem finalidades diferentes em cada uma. Por outro lado,
algumas funes servem de suporte para as funes das outras reas.
Gerenciamento de Falhas
A gerncia de falhas tem a responsabilidade de monitorar os estados dos
recursos, dar manuteno a cada um dos objetos gerenciados, e tomar decises para
restabelecer as unidades do sistema que venham a dar problemas.

As informaes que so coletadas sobre os vrios recursos da rede podem ser
usadas em conjunto com um mapa desta rede, para indicar quais elementos esto
funcionando, quais esto em mau funcionamento, e quais no esto funcionando.
Opcionalmente, pode-se gerar um registro das ocorrncias na rede, um
diagnstico das falhas ocorridas e uma relao dos resultados deste diagnstico com as
aes posteriores a serem tomadas para o reparo dos objetos que geraram as falhas.
O ideal que as falhas que possam vir a ocorrer em um sistema sejam detectadas
antes que os efeitos significativos decorrentes desta falha sejam percebidos. Pode-se
conseguir este ideal atravs do monitoramento das taxas de erros do sistema, e da
evoluo do nvel de severidade gerado pelos alarmes (funo de relatrio de alarme),
que permitem a emisso das notificaes de alarme ao gerente, que pode definir as
aes necessrias para corrigir o problema e evitar as situaes mais crticas.
Gerenciamento de Contabilidade
O gerenciamento de contabilidade possibilita estabelecer-se taxas a serem
utilizadas pelos recursos no ambiente OSI e os custos a serem identificados na utilizao
daqueles recursos. Outras consideraes incluem informaes dos custos dos usurios e
recursos gastos, estipulando limites e incorporando informaes de tarifas em todo o
processo de contabilidade.
No mundo de hoje, contabilidade significa tratar com pessoas usando os reais
recursos de rede com despesas de operao real. Exemplos desses custos incluem uso do
espao em disco e dados armazenados, despesas de telecomunicao para acesso a
dados remotos e taxas de envio de e-mail.
Pode-se tambm usar o gerenciamento de contabilidade para determinar se a
utilizao dos recursos da rede estam aumentando com o crescimento, o que deve
indicar a necessidade de adies e reajustamentos num futuro prximo
Gerenciamento de Configurao
O objetivo da gerncia de configurao o de permitir a preparao, a iniciao,
a partida, a operao contnua e a posterior suspenso dos servios de interconexo
entre os sistemas abertos, tendo ento, a funo de manuteno e monitoramento da
estrutura fsica e lgica de uma rede, incluindo a verificao da existncia dos
componentes e a verificao da interconectividade entre estes componentes.
A gerncia de configurao portanto correspondente a um conjunto de
facilidades que permitem controlar os objetos gerenciados, indentific-los, coletar e
disponibilizar dados sobre estes objetos para as seguintes funes [4]:
9 Atribuio de valores iniciais aos parmetros de um sistema aberto;
9 Incio e encerramento das operaes sobre os objetos gerenciados;
9 Alterao da configurao do sistema aberto;
9 Associao de nomes a conjuntos de objetos gerenciados.
Gerenciamento de Desempenho
Na gerncia de desempenho tem-se a possibilidade de avaliar-se o
comportamento dos recursos num ambiente de gerenciamento OSI para verificar se este
comportamento eficiente, ou seja, preocupa-se com o desempenho corrente da rede,
10
atravs de parmetros estatsticos como atrasos, vazo, disponibilidade e o nmero de

retransmisses realizadas.
O gerenciamento de desempenho um conjunto de funes responsveis por
garantirem que no ocorram insuficincias de recursos quando sua utilizao se
aproximar da capacidade total do sistema.
Para atingir estes objetivos, deve-se monitorar as taxas de utilizao dos
recursos, as taxas em que estes recursos so pedidos e as taxas em que os pedidos a um
recurso so rejeitados. Para cada tipo de monitoramento, define-se um valor mximo
aceitvel (threshold), um valor de alerta, e um valor em que se remove a situao de
alerta.
Definem-se trs modelos para atender aos requisitos de monitoramento de uso
dos recursos do sistema:
9 Modelo de Utilizao: Prov o monitoramento do uso instantneo de um
recurso.
9 Modelo de Taxa de Rejeio: Prov a monitoramento da rejeio de um pedido
de um servio.
9 Modelo de Taxa de Pedido de Recursos: Prov a monitoramento dos pedidos do
uso de recursos.
Gerenciamento de Segurana
O objetivo do gerenciamento de segurana o de dar subsdios aplicaes de
polticas de segurana, que so os aspectos essncias para que uma rede baseada no
modelo OSI seja operada corretamente, protegendo os objetos gerenciados e o sistema
de acessos indevidos. Deve-se providenciar um alarme ao gerente da rede sempre que se
detectarem eventos relativos a segurana do sistema.
As informaes de gerenciamento de segurana so armazenadas numa MIB
especial a qual deve dar apoio as trs categorias de atividades de gerenciamento de
segurana existentes. Esta MIB chamada de SMIB (Security Management Information
Base).
Com base nestas cinco reas descritas acima pode-se chegar ao seguinte
diagrama:
Figura 1. Mensagens num Protocolo de Gerenciamento Fonte: [4].
Onde:
O gerente pode efetuar a solicitao de um dado ao agente e a resposta a este
pedido pode ser enviada pelo agente. H tambm a possibilidade de notificao do
gerente pelo agente em caso de alguma anomalia na rede. As linhas tracejadas
representam operaes opcionais (que eventualmente podem nem ser utilizadas), que
so a escrita de atributos e a leitura destes pelo gerente.
11
Embora esta classificao tenha sido desenvolvida para ambientes de rede OSI
(modelo de sete camadas), esta forma de organizar o gerenciamento da rede tem sido
amplamente aceita por fabricantes de sistemas de gerenciamento, podendo e devendo
ser adotada no escopo do gerenciamento do modelo Internet, foco principal deste
trabalho.
1.4
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 [19]:
9 O trfego, devido s informaes de gerenciamento, no deve aumentar
significativamente o trfego da rede;
9 O agente de protocolo no dispositivo gerenciado, no deve aumentar
significativamente o resultado de processamento a ponto de prejudicar a funo
principal daquele dispositivo.
1.5
Concluses do Captulo
Neste captulo foram descritos os principais conceitos relacionados ao

gerenciamento de redes de computadores, bem como as principais arquiteturas de
gerenciamento de redes. Estes itens so de vital importncia para o entendimento de
outros assuntos que sero descritos ao longo do trabalho.
Apesar de apresentarem objetos distintos, as reas funcionais propostas pela ISO,
relacionam-se no sentido de que informaes geradas em uma determinada rea podem
ser utilizadas como suporte para decises em outras reas [21]. Uma deteco de falha
em um dos componentes da rede, pode por exemplo, ocasionar uma reconfigurao da
rede.
12
2 AMBIENTE DE GERENCIAMENTO ESCOLHIDO

O local/ambiente de gerenciamento escolhido situa-se na Universidade Catlica
de Pelotas UCPel. A UCPel est sediada em Pelotas, importante eixo rodovirio de
ligao com os pases da Bacia do Prata e centro de convergncia da malha rodoviria
do Cone Sul. A cidade localiza-se a cerca de 250 km ao sul de Porto Alegre, s margens
da Lagoa dos Patos e prxima ao porto martimo de Rio Grande, ponto de escoamento
da produo agrcola e industrial da Regio.
Dentro da UCPel, escolheu-se dois ambientes de gerenciamento, sendo eles:
POP UCPel e o NAPI Ncleo de Apoio a Projetos de Informtica.
O POP UCPel o n da Rede Tch instalado na UCPel, responsvel pelo
provimento de servios Internet.
O Ncleo de Apoio a Projetos de Informtica NAPI, tem como objetivo apoiar
projetos da Escola de Informtica, bem como seus executores, dando-lhes suporte
tcnico e administrativo, atravs de infra-estrutura e pessoal de apoio adequado.
A infra-estrututa laboratorial da Escola de Informtica-ESIN compreende um
conjunto de nove salas, utilizadas para atividades de ensino, de pesquisa e de extenso.
Dessas, sete destinam-se prioritariamente ao ensino e a extenso, abrigando em mdia
15 computadores. Duas salas so dedicadas exclusivamente para projetos de pesquisa e
de graduao.
Dentre os equipamentos pertencentes infra-estrutura laboratorial da ESIN,
encontram-se 20 sevidores (PC's, Power PC, RS-6000 e SPARC) com Sistemas
Operacionais disponibilizados 250 PCs com processadores de DX4 100 MHz at
Pentium III 800 MHz.
O ambiente de rede local interligado a Internet via backbone da RNP (Rede
Nacional de Pesquisa) com conectividade de 1 Mbps. Sob a responsabilidade da Escola
de Informtica funciona o Ponto de Presena da Rede TCH, provendo servios de
acesso discado e dedicado para outras Instituies de Ensino e de Pesquisa. Usurios da
UCPel (alunos, funcionrios e professores) dispem de 36 linhas para acesso remoto
(conexo dial-up via circuitos analgicos e digitais).
Mais informaes a respeito da entidade gerenciada, bem como dos ambientes,
podem ser obtidas nas URLs:
http://www.ucpel.tche.br
http://esin.ucpel.tche.br
Sendo assim neste captulo sero apresentadas as caractersticas dos ambientes
de gerenciamento escolhidos para realizao do trabalho, suas finalidades,
configuraes de hardware e software, a topologia da rede, bem como os recursos
humanos para suporte a rea de Tecnologia de Informaes da rede UCPel.
2.1
Estrutura organizacional
13
Figura 2. Estrutura Organizacional.
2.2
Regimento ESIN/NAPI
Captulo I
Do Objetivo
Artigo 10 - O Ncleo de Apoio a Projetos de Informtica (NAPI) um rgo vinculado
Escola de Informtica (ESIN) da Universidade Catlica de Pelotas.
Artigo 20 - O objetivo do NAPI apoiar projetos da ESIN, bem como seus executores,
dando-lhes suporte tcnico e administrativo, mediante infra-estrutura e pessoal de apoio
adequado.
Captulo II
Da Composio
Artigo 30 - O NAPI formado por seus membros, um Conselho Coordenador e um
Coordenador.
Artigo 40 - So membros do NAPI:
i) alunos de cursos de ps-graduao da ESIN;
ii) professores de cursos de ps-graduao da ESIN;
iii) alunos vinculados aos Projetos de Graduao dos cursos da ESIN;
iv) alunos vinculados a Projetos de Pesquisa e Extenso da ESIN;
v) professores com projetos aprovados no NAPI, durante o perodo de execuo do
projeto;
vi) colaboradores formalmente engajados em Projetos do NAPI.
14
Artigo 50 - O Conselho Coordenador do NAPI constitudo pelos seguintes membros:

i) Coordenador do Projeto de Graduao em Anlise de Sistemas (PGAS),
representando os professores orientadores do PGAS;
ii) Coordenador do Projeto de Graduao em Cincia da Computao (PGCC),
representando os professores orientadores do PGCC;
iii) Coordenador dos Cursos de Ps-Graduao da ESIN, representando os professores
dos cursos de ps-graduao da ESIN;
iv) 3 representantes dos professores vinculados a projetos de pesquisa e extenso do
NAPI;
v) 1 representante dos alunos dos cursos de ps-graduao da ESIN;
vi) 1 representante dos alunos vinculados a projetos de pesquisa e extenso da ESIN;
vii) 1 representante dos alunos vinculados a projetos de graduao da ESIN.
10 - Os membros do Conselho sero escolhidos pelos respectivos grupos que
representam, por um perodo de 2 anos.
20 - No caso de no haver cursos de ps-graduao, ficaro vagas as cadeiras no
Conselho dos respectivos representantes de alunos e professores desses cursos.
30 - No caso de falta ou vacncia de algum membro do Conselho, este poder ser
substitudo por outro, escolhido pelo respectivo grupo a quem representa.
Artigo 60 - A administrao do NAPI feita pelo Coordenador que escolhido pelo
Conselho Coordenador, pelo perodo de 2 anos, podendo ser reconduzido por mais um
perodo de igual durao.
Pargrafo nico - Em caso de vacncia ser indicado, pelo Conselho Coordenador do
NAPI, outro Coordenador para completar o perodo
Captulo III
Das Atribuies
Artigo 70 - Compete ao Conselho Coordenador:
i) escolher, destituir e assessorar o Coordenador do NAPI;
ii) avaliar o andamento dos Projetos do NAPI;
iii) decidir pela aprovao ou no dos projetos de ensino, pesquisa e extenso da ESIN;
iv) avaliar e decidir pela aprovao ou no dos participantes dos projetos do NAPI;
v) avaliar e regular a conduta dos membros e dos Projetos do NAPI;
vi) definir e coordenar a poltica de projetos de ensino, pesquisa e extenso da ESIN.
Artigo 80 - So atribuies do Coordenador:
i) representar o NAPI, seus projetos e seus interesses perante a comunidade beneficiria;
ii) zelar pelo bom andamento dos projetos do NAPI e atividades de seus membros;
iii) tratar dos convnios (planejamento, definio, estabelecimento, controle e avaliao)
de projetos do NAPI com a comunidade beneficiria;
iv) seguir as recomendaes e diretrizes estabelecidas pelo Conselho do NAPI;
v) zelar pelas polticas do NAPI;
vi) executar as decises tomadas pelo Conselho do NAPI;
15
vii) divulgar as aes e contribuies do NAPI;

viii) relatar ao Conselho do NAPI o cumprimento dos objetivos, o andamento dos
projetos, bem como obstculos e necessidades para o bom andamento dos projetos;
ix) administrar os recursos materiais e humanos do NAPI.
Captulo IV
Da Comunidade Beneficiria do NAPI
Artigo 90 - A comunidade beneficiria formada por pessoas fsicas ou jurdicas que
so ou possam vir a ser beneficiadas pelos projetos do NAPI.
Paragrfo nico - Incluem-se na comunidade beneficiria, pessoas internas ou externas
UCPel.
Captulo V
Do Uso dos Recursos do NAPI
Artigo 10 - de exclusiva utilizao pelos membros do NAPI, dos recursos materiais e
humanos de que o ncleo dispe, seguindo polticas estabelecidas.
1 - Podem ser admitidas excees desde que devidamente aprovadas pelo Conselho
do NAPI
2 - Cabe ao Conselho Coordenador do NAPI decir a poltica de uso dos recursos
materiais do NAPI e as diretrizes de ao dos recursos humanos alocados ao Ncleo.
Artigo 11 - Independentemente da origem, todos os recursos recebidos pelo NAPI so
por ele administrados.
Captulo VI
Dos Projetos do NAPI
Artigo 12 - Os projetos de ensino, pesquisa e extenso da ESIN devem ser avaliados e,
se aprovados incorporados e supervisionados pelo Conselho Coordenador do NAPI.
Artigo 13 - Os convnios relativos aos projetos do NAPI com a comunidade
beneficiria devem ser avaliados pelo Conselho Coordenador do NAPI
Captulo VII
Das Disposies Gerais e Transitrias
Artigo 14 - Os casos omissos sero resolvidos pelo Conselho Coordenador.
Artigo 15 - O presente Regimento entra em vigor na data de sua aprovao pelo
Conselho Universitrio.
16
2.3
Recursos Humanos
Atualmente a UCPel possui um total de 20 servidores ativos em seu quadro. A

Gerncia de Tecnologia de Informao (GTI), possui duas coordenadorias em sua
estrutura de suporte s atividades de informtica (POP-UCPel e CI Centro de
Informtica), contando com um total de 14 pessoas.
Funo
Coord. Sistemas
Coord. Redes
Coord. Suporte
Analista de Sistemas
Bolsista
Nmero de Funcionrios
01
02
03
02
06
Tabela 1. Recursos Humanos UCPel.
2.4
2.4.1
Especificao e Implementao de um Sistema de Gerenciamento

Sistema de Gerenciamento de Redes
Um Sistema de Gerenciamento de Redes (SGR), pode ser visto como um centro

de gerenciamento. Este centro nada mais do que uma coleo de ferramentas que
possibilitam monitorar e controlar redes. Em arquiteturas de SGRs, pelo menos um dos
computadores na rede designado como estao de gerenciamento (no escopo deste
trabalho a mquina destinada a esta tarefa foi a Mercrio (IP: 200.132.45.44), que ser
descrita mais adiante). Estas estaes caracterizam-se por executar uma interface
homem mquina e por executarem parte das aplicaes de gerenciamento que
desempenham o papel de gerente. A interface homem mquina permite que usurios
autorizados do SGR (administradores), atravs de aplicaes de gerenciamento,
obtenham informaes da rede.
Pode-se ter ainda dois esquemas de gerenciamento [3]:
9 Gerenciamento Centralizado;
9 Gerenciamento Distribudo.
No primeiro, os gerentes residem somente na estao de gerenciamento. J no
segundo, os gerentes residem em mltiplos componentes (ns) da rede. Os agentes
podem residir tanto em computadores Workstations, Servidores, quanto em dispositivos
mais distintos, como hubs, bridges, roteadores e switchs.
Em uma associao de gerenciamento, o componente da rede que implementa o
gerente denominado sistema gerente e o componente que implementa o agente
denominado sistema gerenciado. A figura abaixo ilustra os conceitos de sistema
gerente e sistema gerenciado. Caso o gerente e o agente de uma associao residam em
um mesmo componente, este ao mesmo tempo um sistema gerente e gerenciado.
17
Sistema Gerenciado
Sistema Gerente
Notificaes
Agente
Gerente
Operaes de
Gerenciamento
Objetos gerenciados
MIB
Figura 3.Sistema Gerente e Sistema Gerenciado - [16]-Utilizao Parcial.
2.4.2
Escolha do Servidor - Gerente
Atualmente na hora da escolha de um servidor, pode-se optar por usar um

processador CISC, como por exemplo um Pentium, ou por um processador RISC, como
por exemplo o PowerPC/PowerMac. O servidor escolhido deve ser capaz de lidar com
todas as solicitaes que todas as estaes de trabalho conectadas a ele o fizerem. Se
existir algumas estaes de trabalho fazendo solicitaes ao servidor, mas o servidor
no tiver velocidade suficiente para atender em tempo adequado, ento seu servidor
tornar lento seu ambiente de rede.
No contexto do trabalho, foi escolhida para servidor/gerente a mquina
Mercurio. As caractersticas desta, pode-se observar logo abaixo:
Mercurio
Processador
Memria
HD
Sistema Operacional
IP
Servios
Pentium 350 MHz

64 Mb
4 Gb
Windows 2000 Server
Ingls e Linux Conectiva 6.
200.132.45.44
FTP,
HTTP,
SNMP,
SMTP, POP3, Telnet
Tabela 2. Servidor Gerente.
2.4.3
Sistemas Operacionais da Rede
Aps a escolha do ambiente de rede, deve-se escolher o tipo de sistema

operacional que melhor se ajuste as necessidades em questo. Ser preciso um sistema
operacional Cliente/Servidor, como Linux, Windows NT/2000, Novell, AIX, etc.
Neste caso, como pode ser visto na tabela 2, tem-se dois Sistemas Operacionais:
Linux e Windows 2000. Optou-se por utilizar o Sistema Operacional Windows 2000 pela
maior compatibilidade de softwares de gerenciamento encontrados, conforma ser
descrito no captulo 3.
18
2.4.4
Monitoramento e Controle
O gerenciamento de redes envolve o monitoramento e controle dos recursos da
rede.
9 Monitoramento: a observao, anlise do estado e comportamento dos
recursos fsicos ou lgicos da rede. As funes de monitoramento podem ser
baseadas em read (processos de leitura).
9 Controle: a alterao dos componentes fsicos ou lgicos da rede. As funes
de controle podem ser baseadas em write (processos de escrita).
Funes de Controle
Informaes de Monitoramento
REDE
Figura 4. Noo de Monitoramento e Controle.
2.4.4.1 Monitoramento de Trfego

O monitoramento uma funo de gerenciamento da rede destinada a
observao e anlise do estado e comportamento dos dispositivos gerenciados. Um
usurio, ao utilizar um software gerente para verificar o estado operacional (up ou
down) de uma ou mais interfaces de rede, est efetuando uma funo de monitoramento.
Os responsveis pela resoluo de problemas na rede, podem utilizar dois tipos
de sistemas de monitoramento de trfego. Os softwares para monitorao de meios
fsicos, os quais obtm dados estatsticos a partir de um hub de fiao centralizado e
permitem o controle total das conexes estabelecidas pelos servidores e estaes
clientes da rede. Os analisadores de protocolo de rede, que capturam os pacotes de
dados transmitidos atravs da rede e os decodificam.
2.4.4.2 Controle
O controle uma funo de gerenciamento da rede destinada a alterao de
parmetros de gerenciamento que acarretam aes junto aos dispositivos gerenciados.
Um usurio, ao utilizar um software gerente para desabilitar o funcionamento
temporrio de uma determinada interface de rede, est executando uma funo de
controle.
2.4.5
Alarmes e Acrnicos
Todo o setor de gerenciamento e controle de rede possui dois fatores em comum:
19
a adoo de alarmes e a utilizao de inmeros acrnimos.

O uso de alarmes significa que se instrui o software a chamar a ateno do
administrador quando h ocorrncia de algum evento anormal. Os pacotes de
gerenciamento e controle de rede oferecem respostas para as situaes de alarme que
variam de um registro silencioso do evento no histrico, bips internos, smbolos
coloridos intermitentes na tela durante o envio de mensagens para impressora, Pager,
e-mail e at mesmo o envio de traps..
2.5
Anlise de Hardware e Software
Como j citado anteriormente o ambiente de gerenciamneto ser constitudo pela

UCPel, mais precisamente pelo POP UCPel e o NAPI desta instituio.
Nestes ambientes de gerenciamento, foi escolhido um total de 16 equipamentos.
Destes 7 localizados no NAP e 9 no POP- UCPel.
A seguir observa-se a descrio destes dispositivos:
Equipamentos do NAP I UCPel
Ona:
MrBurns: **
Processador: 166 Mhz
Memria: 64 Mb
Memria: 32 Mb
Hd: 4Gb
Hd: 3Gb
Sistema Operacional: Windows 98 SE
Sistema Operacional: Windows 95
Fabricantes: Infomer
Fabricante: IBM
IP: 200.132.45.19
IP: 200.132.45.177
Dominio: Planeta
Dominio: Planeta
Grupo de Projeto: Rede Tch
Grupo de Projeto: Rede Acadmica
Servidor de Impresso
Vnus:
Pantera:
Processador: 300 Mhz - Celeron
Memria: 32 Mb
Memria: 32 Mb
Hd: 3Gb
Hd: 3Gb
WebCam: Intel
WebCam: Creative
Fabricante: IBM
Fabricante: IBM
IP: 200.132.45.39
IP: 200.132.45.64
Dominio: Planeta
Dominio: Planeta
Grupo de Projeto: Rede Acadmica
Grupo de Projeto: Arca
Tigre:
Leo: **
Memria: 32 Mb
Memria: 32 Mb
Hd: 3Gb
Hd: 3Gb
Sistema Operacional: Linux Mandrak
8.0
Fabricante: IBM
Fabricante: IBM
IP: 200.132.45.52
IP: 200.132.45.51
Dominio: Planeta
Dominio: Planeta
20
Servios Oferecidos: MySQl, PostGres,

FTP, HTTP
EAD: **
Cobra:
Processador: K6 II 333 Mhz
Memria: 64Mb
Memria: 32 Mb
Hd: 5.1
Hd: 3Gb
Sistema Operacional: Windows NT - Sistema Operacional: Windows 98 SE
Server 4 Ingls
Fabricantes: IBM
Fabricantes: Yoshi
IP: 200.132.45.53
IP: 200.132.45.36
Dominio: Planeta
Servios Suportados: Servidor de Bot
Corvo:
Halley: **
Memria: 32 Mb
Memria: 32 Mb
Hd: 3Gb
Hd: 3Gb e 6Gb
Sistema Operacional: Windows NT Server 4 Ingls
Fabricantes: IBM
Fabricantes: IBM
IP: 200.132.45.49
IP: 200.132.45.46
Dominio: Planeta
Dominio: Aulanet
Grupo de Projeto: CSAEA
Servios Oferecidos: Aulanet
Servios Suportados: Mail (SMTP e
POP3), HTTP, IRC (Chat)
Netline:
Mercurio: **
Memria: 32 Mb
Memria: 64 Mb
Hd: 2 e 3 Gb
Hd: 4 Gb
Sistema Operacional: Windows 2000
Server e Conectiva Linux 6.0
WebCam: Intel
Fabricantes: SB Infornatica
Fabricantes: IBM
Zip Drive Interno
Zip Drive Externo
Placa de Video com captura e sada
IP: 200.132.45.34
para TV
Dominio: Planeta
IP: 200.132.45.44
Dominio: Aulanet
Terra:
Parks: **
Processador: 166Mhz
Memria: 256 Mb
Memria: 64Mb
Hd: 2 Scassi (2.1 Gb e 3.2 Gb)
Hd: 4.1 GB scassi
Sistema Operacional: Linux Mandrake
7.1
Fabricantes: SB Infornatica
Placa de Video com captura e sada para Fabricantes: Byte On
TV - ATI
Fita Dat
IP: 200.132.45.45
IP: 200.132.45.43
21
Dominio: Planeta
Hub 3COM Superstack II PS Hub 40: **

24 Portas
IP: 200.132.45.50

Servios
Oferecidos:
Chat,
Ferramentas de Gerenciamento de
Redes
Servios Suportados: FTP, HTTP,
MySQL, SNMP, Mail (SMTP e POP3),
Telnet
Impressora HP Lazer Jet 5M: **
IP: 200.132.45.55
Tabela 3. Equipamentos do NAP UCPel.
** Dispositivos mais importantes do ambiente de gerenciamento NAPI. Os demais

apenas sero includos no SLA como simples dispositivos, no existindo nenhuma
mtrica para estes, a no ser a disponibilidade operacional dos mesmos. O motivo da
no incluso destes dispositivos no contrato deve-se ao fato de estas serem apenas
estaes de trabalho dos usurios.
O servidor Halley onde est instalado o AulaNet, um software destinado a
Educao a Distncia, desenvolvido com base no CGI Lua. Atualmente utilizam o
AulaNet 12 cursos, incluindo disciplinas da rea de informtica, administrao e fsica.
O nmero de usurios cadastrados no AulaNet est em torno de 410.
No Anexo 1, pode-se observar o diagrama do NAPI.
Dispositivos do POP UCPel
Atlas:
Processador: Pentium III 800 MHz;

Memria: 256 Mb;
Hd: SCSI 20 Gb;
Sistema Operacional: Linux Mandrake 8.0;
IP: 200.17.82.34;
Servidor:
E-mail dos usurios, roteamento dos laboratrios, autenticao dos
usurios;
Autenticao:
Samba: nos laboratrios;
TACACS da conexo remota;
Home dos usurios;
Servios: FTP,HTTP, Mail (SMTP e POP3), IMAP4, Telnet.
Triton:
Processador: Pentium 166 MHz;
Memria: 64 Mb;
IP: 200.132.45.56;
Servidor: Projeto de pesquisa.
Hercules:
Processador: Risc RS 6000;
Sistema Operacional: AIX 4.3.2;
22
IP: 200.132.45.54;
Servio: Squid.
Noe:
Processador: Risc RS 6000;
Sistema Operacional: AIX 4.3.2;
IP: 200.132.45.31;
Servidor: Projeto de pesquisa;
Servios: FTP, HTTP, Mail (SMTP e POP3), SNMP, Echo Server, Time Server;
Comunidade de leitura: public.
Amadeus:
Processador: Pentium 200 MHz Pro;
Memria: 128 Mb;
Hd: 8 Gb SCSI;
IP: 200.132.45.55;
Servio: Servidor WEB;
Tabela 4. Dispositivos do POPUCPel.
No Anexo 2, pode-se observar o diagrama do POP-UCPel.

O POP-UCPel, representado no anexo 2, alm destas 5 mquinas possui ainda 1
roteador, 2 Switchs e um bastidor com modens da PARKS.
O roteador, router02.ucpel.tche.br (200.17.82.62) Cisco 2511- o
equipamento mais externo e responsvel pela conexo da UCPel com a UFRGS. O
Link entre as duas instituies de 2 Mb. Sua comunidade de leitura a tango-samba.
Os Switchs presentes no POP UCPel so onde esto ligados os servidores e
demais hosts da ESIN. No Switch 3Com 1100 - Super Stack II (200.132.45.254), esto
ligados os laboratrios (1-5), a recepo do laboratrio, a sala do POP-UCPel, o NAPI
IV e os servidores Noe e Atlas. Sua comunidade de leitura a public. Neste ainda rodam
servios como Telnet, SNMP e HTTP.
Na figura abaixo pode-se observar o que est sendo ligado a cada porta do
Switch.
23
P1: Laboratrio 1
P3: Laboratrio 3
P2: Laboratrio 2
P5: Laboratrio 5
P4: Laboratrio 4
P6: Recepo do Laboratrio
P10: Sala do POP
P13: Teste
P11: Napi IV
P24: Atlas
P23: Noe
Figura 5. Portas do Switch 3COM.
No Switch Cisco Catalyst 1900 Backbone (200.17.82.60), esto ligados os

servidores Triton, Hercules, Amadeus, Atlas e os routers 01,02,03,04. Sua comunidade
a public. Neste ainda rodam servios como Telnet e SNMP.
Na figura abaixo pode-se observar o que est sendo ligado a cada porta do
Switch.
P9: Triton
P13: Hercules
P5: Amadeus
P6: Atlas
P18: Router03
P27: Router04
P21: Router01
P20: Router02
Figura 6. Portas do Switch CISCO.
Um detalhe importante com relao ao servidor Atlas, que este realiza o papel
de bridge entre os dois Switch (3COM e Cisco).
24
2.5.1
Gerente
O gerente compreende um tipo de software que permite a obteno e o envio de

informaes de gerenciamento junto aos mecanismos gerenciados, mediante
comunicao com um ou mais agentes. As informaes de gerenciamento podem ser
obtidas com o uso de requisies efetuadas pelo gerente ao agente, como tambm,
mediante envio automtico disparado pelo agente a um determinado gerente.
Tipicamente um gerente est presente em uma estao de gerenciamento de rede
O gerente foi instalado na mquina Mercurio, j descrita na seo 2.4.2. Para
desempenhar esta funo de gerente, foram escolhidos os softwares WhatsUp, MIB
Master e MRTG (em conjunto com o pacote UCD-SNMP). Estes sero descritos no
captulo 3.
2.5.2
Agente
O agente compreende um tipo de software presente junto aos dispositivos

gerenciados. A funo principal de um agente compreende o atendimento das
requisies enviadas por um software gerente e o envio automtico de informaes de
gerenciamento ao gerente, indicando a ocorrncia de um evento previamente
programado. Tambm compete ao agente efetuar a interface entre os diferentes
mecanismos usados na instrumentao das funcionalidades de gerenciamento inseridas
em um determinado dispositivo gerenciado.
Nos Roteadores, HUBS e Switchs (que possuem capacidade de serem
gerenciados) o agente vem pr-pronto para ser utilizado. Basta habilitarmos e
configur-lo. J em estaes de trabalho/servidores, como Linux, Aix, Windows
NT/9x/2000, devemos instal-lo, configur-lo e habilit-lo.
2.5.3
Implementando o SNMP
Como implementar o protocolo SNMP uma questo encontrada por muitos

administradores de rede. Para a configurao completa do SNMP, alm dos parmetros
de rede (IP do agente, mscara da rede) essenciais para o funcionamento do mesmo,
pode-se tambm alterar os parmetros referentes s permisses das operaes
(community de leitura e community de leitura/escrita). Estes parmetros possuem como
definio default as strings public e private. O endereo IP do gerente que receber
os traps tambm importante que seja configurado para que no haja perda de
informaes. Alm disso, por questes de segurana, pode-se alteradar o status das
operaes SNMP SET. A configurao default deste parmetro habilitada.
A configurao do SNMP foi feita no servidor utilizado para o gerenciamento,
bem como nos dispositivos que sero gerenciados servidores/estaes de trabalho
Linux, Windows NT/2000/9x, roteadores, hubs e switchs.
Abaixo esto os passos para instalao do SNMP no Windows NT/2000/9x, em
seguida os passos para instalao no Linux.
2.5.3.1 Windows NT/2000/9x
Servidores e Workstation Windows NT implementam o protocolo SNMP por um
agente que permite um gerenciamento remoto e centralizado de: Servidores NT,
Workstations NT, Servidores NT baseados em WIN, Servidores NT baseados em DHCP
25
e Servidores NT baseados em IIS.

Servidores e Workstations NT provem o servio SNMP como a estrutura
necessria para o gerenciamento de redes, mas no provm um programa gerente SNMP
[31]. Existem muitas utilidades no gerente SNMP disponveis com o servidor NT e no
kit de recursos para Workstations, alm de outros programas de gerenciamento de redes
de melhor acabamento que podem ser obtidos atravs Microsoft ou por terceiros.
O servidor SMS (Microsoft System Server) fornece suporte para o gerenciamento
SNMP. Outros programas de gerenciamento de redes, assim como Hewlett Packard
Open View, IBM LAN NetView e NMC para Windows NT , alm de outos podem ser
obtidos de terceiros.
A instalao do protocolo SNMP no Windows NT no apresenta muito mistrio,
basta obedecer os seguintes passos: Primeiramente acessa-se o Painel de Controle,
Rede. Na guia Servios, adiciona-se o servio SNMP. Algumas informaes como
contato, localizao, comunidade leitura e escrita, entre outras sero requisitadas. Ser
ento requerido o CD de instalao do Windows NT.
O segundo passo acessar novamente ao Painel de Controle, Servios.
Localiza-se os servios: SNMP e SNMP Trap Service. Configura-se estes servios para
serem inicializados automaticamente. Reinicializa-se o computador e o SNMP j estar
habilitado.
Aps a instalao do SNMP, um grupo de arquivos criado. Entre eles:
9 Dhcpmib.dll: MIB para DHCP. Este s criado quando o servidor DHCP
instalado no computador que roda o servidor Windows NT.
9 Inetmib1.dll: dll para a MIB II.
9 Lmmib2.dll: dll para gerentes de redes LANs.
9 Mgmtapi.dll: Gerente SNMP para Windows NT , que lista para o gerente e
manda e recebe requisies dos agentes.
9 Mib.bin: Instalado com o servio SNMP e usado no gerenciamento de API.
9 Mgmtapi.dll: Relaciona os nomes dos objetos com suas OIDS.
9 Snmp.exe: Servio do agente SNMP, o agente master, que aceita as requisies
do gerente, repassa estas requisies para as dlls apropriadas para o
processamento.
9 Snmptrap.exe: Recebe pedidos SNMP dos agentes e repassa para a API gerente
do SNMP no console de gerenciamento. Um processo em backgraund
snmptrap.exe iniciado somente aps a API gerente receber a autorizao.
9 Winsmib.dll: dll para MIBs WINS, disponveis somente quando o servidor WINS
instalado no computador que roda o Windows NT Server.
No Windows NT toda a configurao do agente ocorre de forma grfica. Na
primeira guia, agente, configura-se o Contact e Location. Alm disso pode-se assinalar
as informaes de servio que deveriam refletir os servios de rede providos por este
computador, no qual esta sendo instalado o agente.
A prxima guia, traps, permite configurar o nome da comunidade e o IP da
mquina que receber as traps. Na terceira e ltima guia, segurana, configura-se as
comunidades do agente e pode-se estipular de quais dispositivos este receber
requisies.
26
Figura 7. SNMP Agente Windows NT.
Figura 8. SNMP Traps Windows NT.
Pode-se ter tantas comunidades quanto o

necessrio.
Figura 9. SNMP Security Windows NT.
2.5.3.2 Linux
O Linux possui um pacote chamado UCD SNMP, atualmente na verso 4.12, o
qual uma implementao do CMU SNMP. Este pacote suporta SNMPv1, SNMPv2 e
SNMPv3, e apresenta uma srie de ferramentas de gerncia utilizveis atravs de linha
de comando.
Para instalar o UCD -SNMP, basta obedecer aos passos listados abaixo:
1) Utiliza-se o comando abaixo, caso seja um arquivo binrio:
% tar xvzf nome do arquivo
Note que este comando ir extrair os arquivos binrios, manuais e outros.
2) Aps entra-se no diretrio descompactado e executa-se o comando ./configure, onde
27
sero pedidas algumas informaes relacionadas a utilizao do mesmo, como local

onde ficaro os logs, contato, localizao, etc. A seguir executa-se o comando make
(make all, make install, make configure), para compil-lo.
3) Se ao invs de um arquivo binrio, for um RPM, utiliza-se:
% rpm i nome do arquivo
Aps a instalao (pelo primeiro ou pelo segundo modo) acrescenta-se uma
entrada em /etc/rc.local para ativar o agente que rodar em background:
% /usr/sbin/snmpd -f ; echo 'snmpd'
Um teste rpido pode ser feito, depois da ativao do agente, executando a
chamada:
% snmpwalk localhost public system
Configurando o snmpd.conf:
Para interagir com SNMPv1, quase nada precisa ser configurado. No arquivo
snmpd.conf possvel personalizar o nome da comunidade, a pessoa responsvel pelo
dispositivo, sua localizao e nome do sistema.
Na primeira verso do SNMP, somente dois tipos de comunidades so possveis;
public e private, sendo que este ltimo pode assumir qualquer nome personalizado pelo
gerente da rede. A est comunidade pode ser atribudo direitos de leitura e/ou escrita.
No diretrio SNMPD, esto os arquivos de configurao importantes (para fazer
uso da segunda verso do protocolo) como o acl.conf e o view.conf, alm do prprio
snmpd.conf. Para fazer alguma alterao vlida no snmpd.conf esta s dever ser feita
no diretrio /usr/share/snmp/snmpd.conf.
9 Party.conf: Define-se endereos IPs, chaves de autenticaes e privacidade dos
grupos;
9 View.conf: Define as sub-rvores da MIB;
9 Context.conf: Define a viso da MIB ou proxy relationship para cada contexto;
9 Acl.conf: Associa dois grupos com um contexto e um conjunto de privilgios.
No arquivo snmpd.conf, localizado no ditetrio /etc/snmp/snmpd.conf, relalizase quase todas as configuraes para um completo funcionamento do SNMP. Quando o
agente comear a rodar, vai ser no diretrio acima que o agente ira procurar as
configuraes para o seu correto funcionamento.
Um fator importante com relao aos seguintes diretrios e seus respectivos
arquivos:
/usr/share/snmp/snmp.conf
Configurao comum para o agente e aplicao. Este normalmente criado no
diretrio /etc/snmp/snmpd.conf, e deve ser movido ou copiado para este caminho
(/usr/share/snmp/snmp.conf), pois neste diretrio que o agente snmpd procura as
configuraes no momento da inicializao.
/usr/share/snmp/snmpd.local.conf
Configura o agente. Este arquivo opcional e s usado para configurar as
pores extensveis do agente, os valores das comunidades. Por padro a primeira
comunidade (a comunidade public) possui acesso somente de leitura e a segunda
comunidade (private por padro) possui acesso restrito.
/usr/share/snmp/mibs
Neste diretrio onde se encontram alguns arquivos texto para implementao
de MIBs no agente.
/var/ucd-snmp
28
Neste diretrio, esto os arquivos relativos ao monitoramento do agente, como

por exemplo logs.
/etc/rc.d/
Neste diretrio ficam os links para os aplicativos que devem ser inicializados na
hora do boot do host.
/etc/snmp
Neste diretrio dica o arquivo snmpd.conf, o qual o arquivo de configurao do
SNMP.
/usr/doc/ucd-snmp-4.1.1
Neste diretrio esto os arquivos de ajuda, a documentao propriamente dita do
SNMP. Aqui encontram-se os arquivos como: agent.txt, example.conf, readme,
snmpcheck, readme.snmpv3, entre outros.
/usr/bin
Neste diretrio estam os arquivo executveis, como por exemplo, snmpd e
snmptrapd.
usr/man
Neste diretrio encontram-se os manuais em formato bz do SNMP.
A seguir feito um relato de algumas configuraes do arquivo snmpd.conf, onde as
linhas que comeam com #, so apenas comentrios.
######################################################################
# Access Control
######################################################################
Aqui definem-se as comunidades de leitura e escrita. Por default a comunidade de
leitura a public.
O snmpd.conf libera apenas o acesso as variveis da categoria sistema (system), ou seja,
todas as outras categorias como ip, tcp, udp, esto bloqueadas. Para se liberar o acesso a
estas informaes deve-se alterar o arquivo snmpd.conf como a seguir:
# context sec.model sec.level prefix read write not
access mygroup "" any noauth 0 mib2 none none
#access admin "" any noauth 0 mib2 system none
access public "" any noauth 0 all none none
access local "" any noauth 0 all all all
Acima pode-se observar na quarta linha a palavra all, access public "" any noauth 0 ->>all<<- none none
No arquivo original, neste campo estava a palavra system. Apenas as variveis da
categoria MIB Sistema estavam liberadas para acesso, ento trocado para all liberou-se
todas as categorias da MIB.
Abaixo tem-se um exemplo dos passos para configurar esta etapa. Note que caso queirase utilizar este exemplo, deve-se apenas modificar a COMUNIDADE para uma nova. O
nome pode ser qualquer um, por exemplo, algo que reflita a rede local do endereo e
espao onde este se encontra.
Por padro o SNMP responde a comunidade public, para acesso apenas de leitura. Podese modificar este nome bem como o da comunidade de escrita por qualquer nome
desejado.
29
#Modelo default VACM

com2sec
group
group
group
view
access
public
public
public
public
all
public
default
v1
v2c
usm
included
""
public
public
public
public
.1
any noauth
exact
all none none
#A comunidade public tem acesso apenas de leitura no snmpd

#Primeiro mapeia-se o nome da comunidade public para um nome seguro:
#
sec.name
source
community
com2sec
notConfigUser
default
public
com2sec
me
localhost
private
###
# Segundo, mapeia-se a segurana dos nomes para dentro dos nomes dos
#grupos:
#
groupName
securityModel
securityName
group
notConfigGroup any
notConfigUser
group
mygroup
any
me
# Tambm adiciona-se um usurio inicial (um usurio snmpv3 configurado
#para todo agente snmpv3) para o grupo:
#
groupName
securityModel
securityName
group
notConfigGroup any
initial
###
# Terceiro, cria-se uma viso para deixar o grupo ter direitos de:
#name incl/excl
subtree
mask(optional)
view systemview
included
system
view systemview
included
interfaces.ifTable.ifEntry.ifOutOctets
view systemview
included
interfaces.ifTable.ifEntry.ifInOctets
view all
included
.1
###
# Finalmente, concede-se ao grupo acesso de somente leitura para o

#systemview:
#
group context sec.model sec.level prefix read
write notif
access notConfigGroup "" any
noauth 0 systemview none
none
access mygroup
"" any
noauth 0
all
all
none
#Este um exemplo de configurao com base nos tpicos acima:
#Deve-se mudar o "smbolo da comunidade" abaixo para um outro nome. Uma
#dica, um nome conhecido em seu local de trabalho ou na sua rede.
##
# com2sec
sec.name
local
source
localhost
community
COMMUNITY
30
com2sec
mynetwork
NETWORK/24
COMMUNITY
##
# group
# group
#
# group
group.name
MyRWGroup
MyROGroup
sec.model
any
any
sec.name
local
mynetwork
MyRWGroup
any
otherv3user
##
# view all
incl/excl subtree
included .1
##
# view mib2
mask
80
-or just the mib2 treeincluded

.iso.org.dod.internet.mgmt.mib-2 fc
##
context sec.model sec.level prefix read write notif
#access MyROGroup ""
any
noauth 0
all
none none
#access MyRWGroup ""
any
noauth 0
all
all
all
######################################################################
# System contact information
######################################################################
Aqui define-se o sysContact e o sysLocation.
syslocation NAPI II / UCPel (edit /etc/snmp/snmpd.conf)
syscontact Mateus(mateus@saturno.ucpel.tche.br)
Aps o comando - snmpwalk -v 1 localhost public system obteria-se os seguintes
dados:
system.sysDescr.0 = 3Com SuperStack II PS Hub 40, SW Version 1.14
system.sysObjectID.0 = OID: enterprises.43.10.27.4.1
system.sysUpTime.0 = Timeticks: (77683032) 8 days, 23:47:10.32
system.sysContact.0 = Mateus(mateus@saturno.ucpel.tche.br)
system.sysName.0 = HUB 3COM
system.sysLocation.0 = NAPI II / UCPel
system.sysServices.0 = 1
Depois de devidamente configurado, o daemon snmpd, este deve ser
inicializado, e sempre que a mquina onde este foi instalado for inicializada, este
daemon tambm deve ser reinicializ-do (/etc/rc/d/init.d/snmpd start).
Mais informaes sobre estes e outros parametros de configurao podem ser
obtidas no arquivo snmpd.conf(5).bz localizado no diretrio /usr/man/man5/.
Nas seguintes e-mails, pode-se consultar uma srie de dicas dos mais variados
assuntos relacionados ao SNMP:
ucd-snmp-announce@ucd-snmp.ucdavis.edu
Para anncios - Subscreva ucd-snmp-anunciar-request@ucd-snmp.ucdavis.edu
ucd-snmp@ucd-snmp.ucdavis.edu
Para discusses de uso do protocolo- Subscreva a ucd-snmp-request@ucdsnmp.ucdavis.edu
ucd-snmp-coders@ucd-snmp.ucdavis.edu
31
Para discusses de desenvolvimento - Subscreva a ucd-snmp-coders-request@ucdsnmp.ucdavis.edu

2.5.3.3 Traps (Linux e Windows NT)
Abaixo sero descritos o SNMPTRAP e SNMPTRAPD nos respectivos sistemas
operacionais Linux e Windows NT.
2.5.3.3.1
SNMPTRAP
uma aplicao SNMP que forma e envia mensagens SNMP TRAPS a um host.
Sintaxe:
snmptrap host community trap-type specific-type device-description [-a agent-addr]
Onde:
9 host: representa a entidade a ser consultada. Pode ser informada tanto pelo nome
ou endereo IP;
9 community: especifica o nome da comunidade para a transao no sistema
remoto. Caso nenhuma comunidade seja passada, ser utilizada como
community default a public;
9 trap-type e specific-type: so inteiros que especificam o tipo de mensagens trap
a serem enviadas;
9 device-description: uma descrio textual do dispositivo que est enviando a
trap, para ser usado como valor de uma varivel system.sysDescr.0 enviada na
lista de variveis desta mensagem;
9 -a agent-addr: pode ser usado para mudar o endereo para onde a trap reporta.
De outro modo, o endereo da mquina de envio utilizado.
Exemplo:
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 saturno 6 0''
Este comando enviar uma trap do tipo enterpriseSpecific. Pode-se observar isto
pelo valor 6, que como poder ser observado logo abaixo define este tipo de trap.
Os tipos de traps padro definidas pelo SNMP so:
9 0 (coldStart): significa que a entidade de protocolo de envio se auto reinicializa
de modo que a configurao do agente ou a implementao da entidade do
protocolo possa ser alterada;
9 1 (warmStart): significa que a entidade de protocolo de envio se auto reinicializa
de modo que nem a configurao do agente nem a implementao da entidade
de protocolo alterada;
9 2 (linkDown): significa que a entidade de protocolo de envio reconhece uma
falha em um dos links de comunicao representados na configurao do agente;
9 3 (linkUp): significa que a entidade de protocolo de envio reconhece que um
link de comunicao representado na configurao do agente voltou a estar
ativo;
9 4 (authenticationFailure): significa que a entidade de protocolo o endereo de
uma mensagem de protocolo que no est apropriadamente autenticada.
Enquanto as implementaes do SNMP devem ser capazes de gerar esta trap,
devem tambm ser capazes de suprimir a emisso dos mesmos via uma
32
mecanismos especfico de implementao;

9 5 (egpNeighborLoss): significa que um vizinho EGP para o qual a entidade de
protocolo de envio, era um parceiro EGP, foi marcada como "down" e o
relacionamento de parceria no existe mais;
9 6 (enterpriseSpecific): significa que a entidade de protocolo de envio reconhece
que algum evento enterprise-especfico ocorreu.
Caso queira-se modificar a porta de envio da trap, basta modific-la no comando
do agente, snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 saturno 6 0 ''.
Por default esta porta a 162. No gerente, que ir receber estas traps, a porta tambm
deve ser a mesma (snmptrapd p 164).
O campo specific-trap identifica a trap particular que ocorreu. Adicionando-se "d" lista de argumentos far com que a aplicao faa um dump dos pacotes enviados e
recebidos.
2.5.3.3.2
SNMPTRAPD
uma aplicao SNMP que recebe e loga mensagens snmp traps enviadas
porta SNMP-TRAP (162) na mquina local. Este deve estar sempre rodando no gerente,
de forma a possibilitar o recebimento das traps .
Sintaxe:
snmptrapd [-p]
Onde:
[-p] a porta em que o daemon snmp ira rodar.
As mensagens tm o seguinte formato:
jul 8 22:39:52 suffern snmptrapd: 128.2.13.41:
Cold Start (0) Uptime:
8 days, 14:35:46
Deve ser executada como root de modo que a porta UDP 162 (caso seja esta)
possa ser aberta.
Um exemplo de trap recebida pelo gerente (de um agente com a seguinte sintaxe
de trap : snmptrap v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 1 0 ) seria:
jul 6 08:09:51 mercurio snmptrapd[952]: 200.132.45.43: Link Up Trap (0) Uptime:
0:36:57.27, interfaces.ifTable.ifEntry.ifIndex.1 = 1
Com o comando snmptrapd c
confFile, o arquivo de configurao
snmptrapd.conf gerado no diretrio /usr/share/snmp/snmptrapd.conf, forando o
agente a ler o mesmo.
O Windows NT, no prov um programa gerente SNMP. Sendo assim, ele apenas
recebe os pedidos SNMP, e repassa para uma API gerente no console de gerenciamento.
Para uma estao Windowsn NT, receber tais traps, este deve utilizar um software
gerente, como por exemplo, MIB Master, capaz de receber as traps enviadas pelos
agentes.
Para uma estao Linux, receber as traps, ela pode utilizar um software gerente,
33
como por exemplo, MIB Master, capaz de receber as traps enviadas pelos agentes ou
ainda pode-se observar as traps enviadas no arquivo syslog, localizado no diterrio
/var/log/syslog:
tail /var/log/syslog
Pode-se direcionar as traps geradas pelos agentes para um outro arquivo que no
seja o syslog. Para isto basta redirecionar as traps do syslog para outro
arquivo qualquer, adicionando as seguintes linhas no arquivo /etc/syslog.conf:
local0.*
/var/log/nome-do-arquivo-desejado.xxx
Exemplos de traps enviadas pelos agentes:
A seguir pode-se observar uma srie de exemplos de traps enviadas pelos
agentes ao gerente.
Exempos:
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 6 0 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 parks 6 1 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 noe 6 0 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 noe 6 1 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 jaguarao 6 0 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 jaguarao 6 1 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 stvitoria6 0 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 stvitoria6 1 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 slourenco 6 0 ''
snmptrap -p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1 slourenco 6 1 ''
No Anexo 4, podese observar uma srie de traps enviadas pelos agentes ao
gerente.
2.5.3.4 Switchs e roteadores
Nos servidores Linux e Windows NT configurou-se apenas um tipo de trap, a
chamada enterpriseSpecific.
Os Roteadores e Switchs possuem diferentes tipos de traps. Sendo assim,
convencionou-se um padro, configurando os mesmos tipos de traps nos diferentes
roteadores e switchs. As traps configuradas foram: coldStart, linkDown/Up, por serem
padres em todos os dispositivos em questo.
2.5.3.4.1
Traps nos Switch e Roteadores
Resumidamente poderia-se dizer que as traps configuradas nos switchs e

roteadores foram as seguintes:
Cold Start
34
9 [2]Coldstart: Switch Cisco Catalyst 1900

9 [2]Coldstart: Switch 3COM 1100 Super Stack II
9 [1]Coldstart: Roteador Cisco 2511
Link UP
9 [4]LinkUP: Switch Cisco Catalyst 1900
9 [4]LinkUP: Switch 3COM 1100 Super Stack
9 [3]LinkUP: Roteador Cisco 2511
LinkDown
9 [3]LinkDown: Switch Cisco Catalyst 1900
9 [3]LinkDown: Switch 3COM 1100 Super Stack II
9 [2]LinkDown: Roteador Cisco 2511
No Anexo 4, podese observar uma srie de traps enviadas pelos agentes ao
gerente.
Tanto switchs quanto roteadores, possuem a capacidade de receberem traps,
contudo, devido ao fato do gerente em questo no ser nem um roteador nem um switch,
e sim servidores Windows NT e Linux, este tema no foi abordado.
2.5.4
As Operaes de Traps
O controle dos eventos extraordinrios de um agente feito atravs de

operaes de traps. A questo : qual a melhor maneira de um agente enviar uma
trap a seu agente de rede sem que a rede fique sobrecarregada? [32]. A operao de
trap definida quanto ao momento de ser enviada e qual o tipo de trap enviar.
Apesar de ser necessrio que o gerente da rede esteja sempre pronto para receber
uma trap, nem sempre isso possvel, devido ao fato de este poder estar executando
outras tarefas.
Se vrios eventos extraordinrios ocorrem, uma poro da banda passante da
rede estar ocupada com informaes de eventos extraordinrios o que pode ser
prejudicial ao trfego normal de dados, violando assim, um dos axiomas de rede.
As traps definidas neste contexto j foram explicitadas anteriormente.
Uma alternativa de trap seria a baseada em polling, ou seja, o gerente da rede
periodicamente, verifica cada agente sobre sua situao.
9 Vantagem: Mantm a figura centralizadora do gerente de rede [21];
9 Desvantagem: Determina o espao ideal entre uma verificao e outra. Sendo
assim se o intervalo for muito pequeno a rede pode ser sobrecarregada com
informaes inteis.
Uma soluo para este problema, seria utilizar um polling orientado
interrupo, ou seja quando ocorrer um evento extraordinrio, o nodo gerenciado envia
uma trap nica e simples ao gerente. Assim o trfego na rede minimizado pois o
gerente passa a ser responsvel por iniciar a interrupo entre ele e o agente para
determinar a natureza do problema, liberando o agente do processamento maior.
2.6
Neste captulo foram descritos os principais conceitos relacionados ao ambiente

de gerenciamento em questo, bem como os procedimentos para a instalao e/ou
habilitao do SNMP nos agentes.
Um fato que constatou-se a fraquesa do agente para Windows (Win9x/NT).
35
Normalmente, eles apenas oferecem suporte a MIB-II, padro. No foi possvel achar
nenhum agente mais "caprichado", com suporte a HostMIB, a qual uma MIB poderosa
para hosts, porque dela podem-se obter informaes sobre um Servidor Web e outros
servios instalados.
Infelizmentte a Microsoft no d muito valor ao SMNP, e prefere utilizar seus
prprios mtodos de gerenciamento.
36
3 SOFTWARES DE GERENCIAMENTO
O crescimento exponncial do nmero de equipamentos interconectados atravs
de redes de computadores tem resultado em enormes dificuldades para os
administradores das redes. O contnuo crescimento em nmero e diversidade dos
componentes das redes tem tornado a atividade de gerenciamento de redes cada vez
mais complexa [2].
O principal objetivo das ferramentas/softwares de gerenciamento auxiliar o
gerente de uma rede no monitoramento e deteco de problemas. Existem basicamente
quatro tipos de ferramentas: ferramentas a nvel fsico, que detectam problemas a nvel
de cabos e conexes de hardware, tais como cabos abertos e mau funcionamento em
hardware de conexo; monitores de rede, que se conectam as redes (um por segmento),
monitorando o trfego. Atravs do exame de infomaes a nvel de pacotes, o monitor
consegue compilar estatsticas referentes a utilizao das redes, tipos de pacotes,
nmero de pacotes enviados e recebidos por cada n da rede, pacotes com erros e outras
variveis importantes; analisadores de rede, que auxiliam no rastreamento e correo de
problemas encontrados nas redes. Para isso apresentam caracteristicas sofisticadas para
anlise do trfego na rede, captura e decodificao de pacotes e transmisso de pacotes
em tempo real; sistemas de gerenciamento de redes integrados (SGRI), os quais
permitem o monitoramento e controle de uma rede inteira a partir de um ponto central.
Esses sistemas apresentam interface grfica com o usurio, seguem o modelo
gerente-agente e realizam gerenciamento de falha, performance, configurao,
segurana e contabilizao.
3.1
Plataforma de Gerenciamento
Uma plataforma de Gerenciamento pode executar vrias aplicaes de gerncia.

Uma poderia se especializar em gerncia de falhas, outra na gerncia de desempenho,
etc. Porm, deve-se lembrar que estas vrias aplicaes tero muitas coisas em comum.
Todas devem por exemplo, saber a topologia da rede, todas devem ter mecanismos de
conversa com agentes atravs do protocolo de gerncia, todas devem ter formas simples
de apresentar informao grfica ao usurio, etc.
Uma plataforma de Gerncia um software especial que possui as seguintes
caractersticas:
9 Contm toda a funcionalidade comum a vrias aplicaes de gerncia. Isso
inclui algoritmos de auto-descobrimento de topologia, um editores grficos de
topologias, uma base de dados de tecnologia, rotinas de acesso a MIB dos
agentes utilizando o protocolo de gerncia, armazenamento dos valores
recebidos dos agentes numa base de dados, etc.
9 Contm uma aplicao simples de gerncia que permite, pelo menos, visualizar
graficamente a evoluo com o tempo dos valores das variveis dos agentes.
Este tipo de aplicao chama-se MIB Browser.
9 Contm uma API (Application Programming Interface) que permite que vrias
aplicaes especiais sejam construdas e inserdas na plataforma lanando mo
de todos os recursos oferecidos pela plataforma.
9 Apresenta uma interface amigvel com o usurio, permitindo que qualquer
usurio interaja sem necessidade de treinamento, preferencialmente baseada na
WEB.
9 Livre de plataforma, podendo assim gerenciar qualquer dispositivo independente
37
da plataforma.
9 Monitoramento do trfego em um agente atravs de grfico. Atravs, destes
grficos podem ser feitos levantamentos do perfil do tfego, verificando a
performance do equipamento e o trfego total em um agente SNMP. Este ltimo
fator dado em relao a taxa total de bytes que um agente recebe ou transmite
durante um ciclo de leitura (Polling). Esta taxa obtida pela diferena entre a
leitura atual dos valores dos objetos da MIB e a leitura ocorrida no ciclo anterior.
Todos estes fatores foram levados em conta na anlise/escolha do(s) software(s)
de gernciamento, a serem utilizados neste trabalho.
3.2
Softwares de Gerenciamento
Nesta seo realizada uma anlise de vrios softwares para gerenciamento de

redes, com o uso do protocolo SNMP. Existe um nmero impressionante de ferramentas
destinadas gerncia de rede e administrao remota. Algumas ferramentas incluem
anlise do trfego da rede, segurana de rede, monitoramento, configurao, etc.
A soluo tpica para a gerncia de redes a utilizao de Plataformas de
Gerenciamento Fechadas, as tambm chamadas ferramentas de software comerciais
de gerenciamento. Entretanto, alm dos custos elevados envolvidos neste tipo de
soluo, por envolver hardware, sistema operacional e finalmente a prpria plataforma
tem-se ainda agravantes como dificuldade na instalao e uma curva de aprendizado
muito grande por parte dos usurios, exigindo grande especializao.
Com base nos conceitos vistos nos captulos anteriores, realizou-se uma anlise de
vrios softwares capazes de gerenciar dispositivos em redes de computadores atravs da
obteno de estatsticas de utilizao, status da operao, condies de erro,
diagnstico, etc., com diferentes funcionalidades de gerenciamento de redes,
priorizando sempre aquelas chamadas Plataformas de Gerenciamento Aberto.
Analizou-se 36 softwares. Aps uma anlise detalhada de cada um destes
softwares, chegou-se aos softwares que seriam utilizados para o gerenciamento em
questo.
9 WhatsUP;
9 MIB Master;
9 MRTG.
O propsito inicial, era a utilizao de um nico software, o WhatsUP, mas
devido as carncias apresentadas por tal, houve a necessidade de se mesclar outros
softwares para o complementarem.
A seguir est uma relao de alguns dos softwares testados com suas descries.
Logo aps realizada uma descrio do(s) software(s) escolhido(s) para a continuao
do trabalho.
38
SOFTWARES
Servers Alive
WhatsUP
AdventNet V5
Monitor
AdventNet
SNMP Utilities
Network View
UCD SNMP
MRTG
Plataforma
Windows
95/98/NT/
2000
Windows
95/98/NT/
2000
Windows
95/98/NT/
2000 e Linux
Windows
95/98/NT/
2000 e Linux
Windows
95/98/NT/
2000
Windows
95/98/NT/
2000 e Linux
Unix/Linux e
WindowsNT
RRDTools
Unix/Linux e
WindowsNT
MIB Master
Windows
95/98/NT/
2000 e Linux
Windows NT,
Unix e AIX
WindowsNT
NetView
Uni Center
TNG
NetSaint
Sniffer
Tivoli TME10
Brightwork
Utilities for
Netware
Scotty
CARACTERSTICAS
Fabricante
Site do Fabricante
Woodstone http://www.woodstone.nu
Computer
Consulting
IPSwitch
http://www.ipswitch.com
Advent
http://www.adventnet.com
Advent
http://www.adventnet.com
Network View http://www.networkview.com
University of
California,
Davis
Tobias Oetiker
e muitos
contribuintes
Tobias Oetiker
e muitos
contribuintes
Equivalence
IBM
Unicenter
Linux
Windows
95/98/2000/NT
Linux
Windows
95/98/2000/NT
NetSaint
Network
Associates
Tivoli
Mcafee
Associates
Linux
Universidade
Tcnica de
Braunschweig
Asant
Technologies
HP
IntraSpection
Windows NT
HP Open View
Extensible
SNMP Agent
SunNet
Windows
95/98/2000/NT
Windows
Sun
http://ucd-snmp.ucdavis.edu
http://ee-staff.ethz.ch/~oetiker/
webtools/mrtg/mrtg.html
http://ee-staff.ethz.ch/~oetiker/
webtools/rrdtool
http://www.equival.com
http://www.tivoli.com/products/in
dex/netview
http://www.unicenter.com
http://www.netsaint.org/
http://www.nai.com.br/
http://www.tivoli.com/
http://www.mcafee.com/
http://ftp.unicamp.br/pub/network
/tkined/
http://www.dsc.ufpb.br/~dea/text
os/A028.html
http://www.hp.com
http://sun.com
39
Manager
Frye Utilities
for Networks
Netware
Management
95/98/NT/2000
Windows
95/98/2000/NT
Microsystems
Frye Computer http://www.frye.com/
Systems
Tabela 5. Anlise de Softwares.
Na URL: http://www.interaccess.com.br/mateus
documentao mais detalhada a respeito de tais softwares.
3.2.1
pode-se
observar
uma
WhatsUP
Figura 10. Whats UP Gold.
Plataforma: Windows 95/98/NT/2000

Fabricante: IPSwitch
Site do Fabricante: http://www.ipswitch.com
Verso: 6.0
Preo: $ 695,00
Tamanho do Instalador: 11,12 Mb
Nvel de Instalao: Fcil
Espao que ocupa aps a instalao: 18 Mb
Requisitos de mquina: PC 486/66 MHz, 15 Mb de espao em disco, 16 Mb de
memria RAM (Win 95/98) /32 MB de memria RAM (Windows NT / Windows 2000).
Caractersticas:
Recentemente foi divulgado pela Cisco a adeso do WhatsUp na nova verso do
software CiscoWorks Windows, oferecendo maior capacidade de gerenciamento para
redes e workgroups de pequeno e mdio porte.
O WhatsUp Gold da Ipswitch, confere aos administradores de redes a capacidade
de descoberta, mapeamento, monitoramento e notificao. Com capacidades para
verificar o status da rede em tempo real, os clientes podem monitorar todo o hardware
de rede: PCs, servidores, roteadores, repetidores, concentradores LAN, impressoras e
dispositivo de usurio final; alm de servios como SMTP, POP3, FTP, Telnet, WWW e
NNTP a partir de uma nica aplicao.
O WhatsUP, permite monitorar alm destas portas/servios j pr-definidos pelo
software, uma srie de outras portas/servios que podem ser configurados pelo
administrador da rede. Basta para isso informar em qual porta est rodando o servio ou
aplicao que se deseja monitorar.
Apresenta uma boa interface, com fcil instalao e utilizao. Permite mapear a
rede ou montar uma rede personalizada. Os mapas so criados atravs do escaneamento
de redes TCP/IP, Novell NetWare IPX, e Microsoft NetBIOS.
Quando o WhatsUP inicializado duas opes so disponibilizadas:
9 Discover and Map Network Devices;
40
9 Create a Blank Map.
Figura 11. Tela inicial do WhatsUp.
Escolhendo a primeira opo, o WhatsUp, se encarregara de vasculhar a rede em

busca dos dispositivos presentes.
Ao criarmos um host ou clicarmos em um host j definido, nos apresentada
uma tela com uma srie de utilitrios:
Guia Geral:
Nesta guia tem-se informaes como o nome do host, o nome que vai aparecer
no mapa, o endereo IP, o tipo de mquina: se Servidor, Workstation, Hub, Bridge,
Router, Impressora, Winsows NT Server, Windows NT Workstation. Tambm pode-se
escolher o mtodo de Polling: ICMP, TCP/IP, NetBIOS, IPX.
Figura 12. Guia Geral.
41
Guia SNMP:
Nesta guia pode-se definir a comunidade de leitura e de escrita de um
determinado host com suporte a SNMP. O Object ID automaticamente posto aps o
escaneamento da rede. Ele tambm recebe as traps enviadas pelos agentes ou gerentes.
Basta para isto configurar a porta de escuta, que deve ser a 10048. As traps ficam todas
armazenadas em um arquivo de log, que podem ser conferidas na guia Logs. Porm
apesar deste software receber traps, ele apresenta muita instabilidade quanto a este
fator, sendo que em muitos casos, para no dizer na maioria, as traps acabam no sendo
recebidas pelo gerente. Sendo assim, para suprir esta deficincia, foi escolhido o
software MIBMaster que ser descrito mais adiante.
Figura 13. Guia SNMP.
Para que o Object ID seja identificado, necessrio que as comunidades de

leitura e/ou escrita estejam corretas.
O WhatsUp utiliza o SNMP para montar redes separando-as de acordo com os
nveis de subrede. Aps a criao do host, ao clicar-se com o boto direito em cima do
mesmo, a opo SNMP estar disponvel onde tem-se o IP do host, sua comunidade e as
opes get, get next, get all subitems e monitor. Esta ltima opo tambm chamada
de WhatsUp Gold Graphing Utiliy , o qual discutido logo a seguir.
Guia Monitor:
Nesta guia tem-se algumas opes de monitoramento. Nela pode-se determinar a
frequncia de Poll, o tempo de timeout, os dias e horrios de monitoramento para aquele
host e a quem um determinado host estar conectado.
42
Figura 14. Guia Monitor.
Guia Services:
Na guia servios o WhatsUp possibilita um escaneamento automtico de um
determinado host identificando de forma automtica os servios disponibilizados pelo
mesmo.
Figura 15. Guia Services.
Guia Alerts:
As notificaes podem ocorrer atravs de alarmes sonoros, traps SNMP, e-mail,
pager, bip ou execuo de algum programa, para uma ou para um grupo de pessoas.
43
Figura 16. Guia Alerts.
Configurou-se 3 tipos de alertas/notificaes:

9 Alarme sonoro;
9 Traps SNMP;
9 E-mail.
As traps so utilizadas para notificar o administrador/gerente sobre eventuais
problemas que venham ocorrer no dispositivo/agente gerenciado. Para realizar uma
notificao via trap, basta configurar a aporta de escuta no WhastUP. Esta porta deve
ser a 10048.
Note que para o WhatsUp receber estas traps elas devem ter sido previamente
configuradas nos agentes.
As notificaes neste caso so visualizadas atravs de um outro software,
chamado MIBMaster, pois como visto anteriormente apesar do WhatsUP receber traps,
ele apresenta muita instabilidade quanto a este fator, sendo que em muitos casos as
traps acabam no sendo recebidas pelo gerente.
A notificao por e-mail de grande utilidade pois permite ao administrador
verificar possveis problemas que estejam acontecendo nos dispositivos gerenciados de
uma mquina qualquer. As notificaes chegam ao WhatsUP e este como forma de
alerta envia uma mensagem para o administrador com o(s) problema(s). Abaixo pode-se
observar um exemplo de notificao feita pelo WhatsUP ao administrador:
De: WhatsUp <whatsup@mercurio.ucpel.tche.br>

Data: Friday, jul 06, 2001 9:52 PM
Para: mateus@floripa.com.br
Assunto: server halley SMTP SVCDOWN at 21:52:23
Server halley SMTP SVCDOWN at 21:52:23
Address: 200.132.45.46
Info 1:
Info 2:
Date: 06/07/2001
Status: Active and responding ( 0)
Svcs: SMTP
Notes:
-Sistema Operacional: WindowsNT Server
-IP: 200.132.45.46
44
-Servios: Mail (SMTP e POP3), SNMP e HTTP

-Comunidade de leitura: public
O WhatsUp permite ainda enviar e-mails para celular. Esta funcionalidade de
vital importncia, pois permite que o administrador saiba imediatamente quando um
determinado problema ocorreu estando ele onde estiver.
Abaixo pode-se verificar alguns exemplos de mensagens enviadas a um celular:
De: WhatsUp@ mercurio.ucpel.tche.br
Assunto: Server Atlas HTTP SVCDOWN at 08:24:43
O nico problema com estas mensagens enviadas por e-mail pelo whatsUP o
excessivo nmero de mensagens que este gera. Qualquer problema que ocorra em um
dispositivo monitorado, desde um equipamento parado ou servio parado at uma
pequena perda de pacotes enviados pelo software ao dispositivo gerenciado, realizado
uma notificao. Note que ele notifica quando um host/servio ficou Down e tambm
quando este voltou a ficar UP.
Guia Notes:
Nesta guia onde esto as informaes gerais a respeito de um determinado host. Estas
informaes devem ser colocadas de forma manual pelo administrador da rede ou pela
pessoa que for a responsvel pela utilizao do software.
Figura 17. Guia Notes.
Guia Menu:
A ferramenta inclui os servios: Ping, Traceroute, Lookup, Finger, Whois,
LDAP, Quote, Scan, SNMP, e Throughput; e permite configurar aplicaes de FTP e
Telnet. Estas ferramentas podem ser utilizadas para anlisar o comportamento dos
objetos gerenciveis.
45
Figura 18. Guai Memu.
Aps criado o host, ao clicar-se nele, novas funes/guias estaro includas:

Status:
Mostra o status da mquina indicando quais servios esto rodando, quais esto
OK e quais esto com problemas. Neste exemplo pode-se ver que o servio SMTP da
mquina Saturno (http://saturno.ucpel.tche.br) est com problema.
Figura 19. Guia Satus.
Up-Time:
Indica o perodo em que determinado dispositivo est UP.
Log:
Gera um arquivo com todas as requisies e operaes realizadas pelo host. Tambm
armazena informaes referentes a traps recebidas pelo gerente.
46
Figura 20. Guia Logs.
Uma outra caracterstica deste software o fato de gerar relatrios de eventos,

facilitando assim o trabalho do administrador, que pode identificar os dias (dia, ms,
ano, hora) em que houveram problemas em um determinado host, ou quais os dias em
que houve mais trfego na rede.
47
Figura 21. Relatrio de eventos gerado pelo WhatsUp.
48
Figura 22. Relatrio de estatsticas gerado pelo WhatsUp.
O WhatsUp apresenta um utilitrio chamado WhatsUp Gold Graphing Utility,

que como o prprio nome diz um grfico das variveis de trfego de interfaces de
rede.
49
Figura 23. WhatsUp Gold Graphing Utility.
Este grfico de desempenho demonstra os dados agregados a um determinado

dispositivo, exibindo a melhor e/ou pior disponibilidade, 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.
O WhatsUp, utiliza diferentes cores para os hosts, indicando seu estado:
9 Verde: O host est OK, respondendo a todos pollings;
9 Amarelo: O host, perdeu alguns pedidos de pollings;
9 Vermelho: O host no est acessvel ou no responde;
9 Roxo: Est com algum servio Down ou esta tendo perda de pacotes enviados a
um determinado servio.
3.2.1.1 Instalao de um servidor WEB
O WhatsUp possui um servidor WEB prprio. atravs deste servidor que as
pginas HTML geradas pelo WhatsUp nos so disponibilizadas. Est caracterstica, de
gerar pginas WEB, de vital importncia pois propicia ao administrador da rede um
apoio remoto, podendo dar manuteno a qualquer mquina de qualquer lugar do
mundo, bastando para isto ter um browser instalado na mquina.
Esta interface Web ainda a nica forma que usurios comuns tero de obter
informaes referentes a um determinado host/ambiente gerenciado.
Com relao as permisses destas pginas geradas, pode-se controlar o acesso as
estas, ou seja, restringindo ou liberando o acesso a usurios e mquinas pr definidas. O
usurio dependendo das suas permisses pode por exemplo visualizar mapas, status dos
dispositivos e logs, configurar mapas, adicionar e remover dispositivos, gerar relatrios,
configurar alertas e cadastrar usurios.
Na figura abaixo pode-se observar a interface Web de inicializao do WhatsUp.
50
Figura 24. Pgina WEB gerada pelo WhatsUP.
Nesta tela tem-se vrias opes. Nela so listados todos os ambientes de

gerenciamento disponveis. Note que no exemplo acima tem-se 4 ambientes:
9 Ambiente de Gerenciamento POP / UCPel;
9 Ambiente de Gerenciamento NAPI II;
9 Ambiente de Gerenciamento Extenes UCPel;
9 Ambiente de Gerenciamento Provedor SuperSul.
Ao lado de cada ambiente so mostradas informaes referentes aos dispositivos
presentes naquele ambiente. Estas informaes dizem respeito a informaes como
Items UP, Items Down e Services Down.
Os Items UP dizem respeito aos dispositivos de rede ativos e respondendo no
momento. Os Items Down referem-se a dispositivos de redes no ativos e respondendo.
Os Services Down referem-se aos servios no ativos.
Abaixo, no rodap do WhatsUP, existem dois Links para dois outros softwares
que como descrito anteriormente foram utilizados para suprir algumas carncias do
WhatsUP. Estes Softwares so o MIB Master e o MRTG, ambos sero discutidos nas
sees seguintes.
Nesta tela da figura 24, a direita, temos ainda as seguintes opes:
Settings:
Permite alterar-se as opes de exibio das pginas HTML. Opes como:
9 Ttulo da pgina;
9 Diretrio e consequentemente o mapa que ser inicializado quando o WhatsUp
51
9
9
9
9
for carregado;
Diretrio onde se localizam as pginas Web;
Tempo de refresh (atualizao da pgina);
Informaes como cabealho e rodap da pgina;
Cor de fundo e da fonte da pgina.
New Map:
Permite a criao de um novo mapa (ambiente de gerenciamento). Para isto
deve-se preencher os seguintes campos:
9 Map Name: Nome do Mapa;
9 Title: Ttulo do Mapa (nome que ser exibido na tela inicial figura 24);
9 Active: Permite ativarmos ou no o auto polling do mapa.
9 Pool Timer (seconds): Nmero de segundos entre as inicializaes de pollings.
9 Timeout (seconds): Nmero de segundos que o WhatsUP espera pela resposta de
um determinado host ou servio.
Note que nesta opo apenas cria-se o ambiente do mapa e suas
caractersticas. Para adicionar-se ou remover-se um dispositivo deve-se, como ser visto
mais adiante, clicar-se no mapa/ambiente que deseja-se e na guia ferramentas (tools) e
adicionar-se ou remover-se um detreminado dispositivo ou servio.
Load Map:
Carrega (abre) um mapa de rede j existente.
Unload Map:
Descarrega (fecha) uma mapa de rede existente.
Notifications:
Como j visto anteriormente o WhatsUP permite a notificao ao administrador
com relao a eventuais problemas em um determinado host ou servio. Esta
notificao pode ser feita por e-mail, pager, celular, alertas sonoros, etc. Nesta guia
pode-se definir (adicionar, remover ou editar) diferentes tipos de notificao, bem como
diferentes receptores de tais notificaes.
Reports:
Permite definir-se relatrios. O WhatsUp envia relatrios do estado da rede
(dispositivos e servios). Estes relatrios podem ser enviados diariamente ou em dias
pr-definidos. Uma das grandes vantagens destes relatrios a notificao completa de
todos os problemas ocorridos com um determinado dispositivo.
A seguir pode-se observar um trecho de um relatrio enviado pelo WhatsUp:
52
---------- Forwarded message ---------Date: Tue, 24 Oct 2000 15:00:01 +0100

From: WhatsUp <whatsup@mercurio.ucpel.tche.br>
To: mateus@floripa.com.br
Subject: WhatsUp Report 16 up 0 down 1 svcdown
WhatsUp Report
All 16 hosts are reachable
Roteador - Cisco 2511 Amadeus Atlas Triton Hercules Noe Switch Cisco Catalyst 1900
Switch - 3COM Halley Mercurio - Gerente Saturno Jaguaro Santa Vitria So
Loureno Piratini Canguu
Down Svcs: 1
Noe
Log File:
20001024 1542 Log cleared at user request.
20001024 1558 Web server started on port 90
Users:
Permite definir-se novos usurios ou editar-se usurios j existentes. Nesta guia
define-se tambm as permisses de cada usurio..
Tools:
Possibilita acesso a 4 ferramentas: Ping, Trace Route, Lookup e Scan. Nesta guia
tem-se uma srie de informaes que devem ser preenchidas para o correto
funcionamento de tais ferramentas.
9 Name/Adress: Nome ou IP do dispositivo que se deseja verificar.
9 Ping Count: Utilizado com a ferramenta de Ping. Neste campo entra-se com o
nmero de pacotes que sero enviados pelo comando. O padro 5.
9 Trace max hops: Utilizado com a ferramenta Trace. Neste campo entra-se com o
nmero mximo de hops. Mximo de 32 hops.
9 Lookup Type:
9 A: IP Adress;
9 PTR: Nome do dispositivo;
9 CNAME: Nome primario do dispositivo;
9 HINFO: Tipo de CPU e sistema operacional do dispositivo;
9 MX: O dispositivo que age como cambista (troca) de e-mail;
9 NS: Name Server para zona nomeada.;
9 SOA: Comeo do domnio de informaes de autoridade.;
53
9 ALL: Todas informaes.

9 Lookup Server: Pode-se obter informaes com relao a um determinado
dispositivo.
9 Scan first port: Primeira porta que se deseja escanear.
9 Scan last port: ltima porta que se deseja escanear.
9 Scan timeout: Tempo mximo de espera por resposta de uma determinada porta.
Caso ao final deste tempo no se obtenha resposta, automaticamente se passa
para uma outra porta. Note que todas estas configuraes podem ser feitas diretamente
no console.
Caso se deseje saber informaes mais detalhadas a respeito de um determinado
ambiente, basta clicar-se no link referente a este ambiente que uma outra pgina nos
ser disponibilizada figura 24.
Figura 25. Pgina Web de um determinado Ambiente de Gerenciamento.
A direita desta tela, uma outra srie de menus so disponibilizados, onde:

Top view:
Retorna a pgina principal figura 24.
Summary view:
54
Exibe uma srie de informaes relacionadas a aquele ambiente gerenciado.
Figura 26. Guia Summary View.
Na guia acima h informaes relacionadas a todos os dispositivo do ambiente

bem como os servios disponveis em cada um com a respectiva taxa de resposta.
Com relao a esta taxa importante salientar, que quando um dispositivo ou
servio apresentar-se roxo, no significa que o dispositivo ou servio esteja parado. O
que est acontecendo pode ser simplesmente perda de pacotes. Nesta guia pode-se ento
acompanhar o percentual de perda.
Log view:
Nesta guia pode-se ver os logs das atividades.
Stats view:
Nesta guia pode-se ver os logs das estatsticas.
Settings:
Podem-se alterar informaes relacionadas ao MAPA em si, como por exemplo o ttulo.
Reset counters:
Zera os contadores de estatsticas. No existe nenhuma opo semelhante no console.
55
Add host:
Permite adicionar um determinado dispositivo. Sero solicitadas informaes como:
Ttulo, host name, ip, Tipo de polling, tipo de dispositivo, dias em que ser monitorado,
etc.
Remove host:
Permite remover um determinado dispositivo.
Event Report:
um relatrio de eventos. criado com base nos logs armazenados no Events Logs.
Statistics Report:
um relatrio de estatsticas. criado com base nas estatsticas de polling.
Tools:
Funcionalidade j descrita anteriormente.
Acknowledge:
Este boto aparece somente quando existirem alertas no respondidos.
Pode-se ainda obter informaes mais especficas relacionadas a um determinado host.
Para isto basta clicar-se no host desejado. Uma outra pgina apresentada, como a que
segue a seguir:
56
Figura 27. Detalhamento de um host.
Nesta pgina, no seu topo, h informaes relacionadas ao nome e IP do

dispositivo. A seguir tem-se o seu estado, se esta ativo e respondendo por exemplo.
Logo aps informaes relacionadas as suas estatsticas, indicando o percentual de
reposta dos servios de um determinado dispositivo.
No rodap da pgina, so gerados logs dos dispositivos. A direita tem-se uma
srie de comandos:
Top view:
Retorna a pgina principal - figura 24.
Map view:
Retorna a pgina principal do ambiente figura 25.
Summary view:
57
Log view:
Stats view:
Settings:
Permite realizar alteraes (host name, IP, caractersticas, etc.) no dispositivo em
questo.
Reset counters:
Services:
Habilitar ou desabilitar servios no dispositivo. Pode-se habilitar ou desabilitar servios
como: FTP, HTTP, SNMP, SMTP, POP3, IMAP4, Gopher, Telnet, Echo, etc.
Alerts:
Tools:
O WhatsUP, possui ainda um utilitrio, extremamente til, chamado MIB
Browser, o qual permite uma viso geral da MIB do dispositivo.
58
Figura 28. Mib Browser
3.2.2
MIB Master
Figura 27. MIBMaster.
Plataforma: Windows 95/98/NT/2000 e Linux

Fabricante: Equivalence
Site do Fabricante: http://www.equival.com
Verso: 1.5pl5
Preo: O MIB Master parou de ser fabricado.
Tamanho do Instalador: 1,29 Mb
Nvel de Instalao: Fcil
Espao que ocupa aps a instalao: 2,08 Mb
Requisitos de mquina: PC 486 DX4 /100 MHz, 8 Mb de memria.
Caractersticas:
59
Figura 30. Tela inicial do MIB Master.
Aps instalado o MIB Master, para um bom funcionamento devem-se configurar

alguns parmetros:
Changing global parameters:
A pgina de Parmetros Globais permite modificar parmetros de configurao
do MIB Mster. Para mudar qualquer um dos parmetros nesta pgina, simplesmente
entre-se com o novo valor no campo apropriado e aperte-se o boto "Aceitar. Abaixo
so listados os parmetros de configurao:
Default Host Name:
Neste campo define-se qual dispositivo que ser exibido na primeira tela do MIB
Master. Pode ser seu hostname ou seu IP. Se este campo ficar vazio, o hostname
exibido ser o da mquina corrente.
Default Get Community:
Este campo fixa o nome da comunidade padro usada por todos os pedidos
SNMP adquiridos.
Default Set Community:
Este campo fixa o nome da comunidade padro usada para todos os pedidos
SNMP definidos.
60
Seperate set community:

Como default na tela inicial o MIB Master apresenta apenas a Get Community.
Setando-a uma outra opo apresnetada, a Set Community.
Default Protocol:
Alguns sistemas operacionais podem apoiar mais de um protocolo de transporte
para SNMP. aqui que define-se qual ser o padro no boto radiobox da tela inicial do
MIB Master.
Log Level:
Aqui, pode-se configurar o nvel dos logs. Este apresenta 5 nveis, onde pode-se
filtrar os tipos de mensagens que o MIB Master envia:
1 Apenas os erros fatais;
2 Todos os erros;
3 Advertncias;
4 Todas as mensagens;
5 Depura as mensagens;
SNMP Timeout:
Aqui define-se o perodo mximo de tempo que o MIB Master esperar para
adquirir ou fixar/setar uma requisio SNMP. O valor padro 5 segundos, podendo ter
seu tempo aumentado para redes congestionadas.
SNMP Retries:
O SNMP Retries representa o nmero mximo de tempo em que o MIB Master
ir reenviar os pacotes de SNMP. O valor padro 5 segundos, podendo ter seu tempo
aumentado para redes congestionadas.
O MibMaster recebe traps enviadas por um gerente ou agente, ou seja, funciona
como um software gerente. Para isto basta configurar a porta de escuta de maneira
correta, por default esta porta a 162.
Transmit Buffer Size:
Este campo fixa o tamanho mximo de qualquer pacote SNMP que o MIB
Master gerar. O valor padro deste campo 484 bytes que o tamanho mximo que
qualquer implementao do SNMP devera receber.
Fazendo este pacote utilizar o tamanho mximo, o tempo gasto para recobrar
MIBs muito grandes ser reduzido, mas pode causar um problema que no obter
nenhuma resposta, pois a implementao do SNMP pode no apoiar o tamanho
configurado.
Receive Buffer Size:
61
Este campo fixa o tamanho do buffer usado pelo MIB Master para receber
respostas e pedidos do SNMP. O valor padro deste campo 1500 bytes que deve ser
grande o bastante para controlar pacotes gerados pela maioria das implementaes
SNMP.
Se o MIB Master receber uma resposta que maior que este tamanho o Buffer
Size, executar o pedido novamente com menos tens.
HTTP Port:
Aqui define-se o parmetro da porta HTTP que ser fixada para o MIB Master
usar. O valor de padro 1090.
Exemplo: http://casanova.ucpel.tche.br:1090
Username and Password:
O Username e o Password permitem controlar o acesso ao MIB Master. Sem
este username e password, um usurio s poder ter acesso a home page do MIB
Master, e as pginas de Ajuda On-lines.
Admin Username and Password:
O Admin Username e o Password permitem controlar o acesso a
programao/configurao do MIB Master. Sem este username e password, um usurio
no poder ter acesso as configuraes do MIB Master.
Na figura abaixo, pode-se observar a tela que contm todos estes parmetros citados:
Figura 31. Tela de configuraes do MIB Master.
62
3.2.3
MRTG
Figura 32. MRTG.
Plataforma: Unix/Linux e WindowsNT

Fabricante: Tobias Oetiker e muitos participantes.
Site do Fabricante: http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/mrtg.html
Verso: 2.8.12
Preo: Freeware
Tamanho do Instalador: 705 Kb
Nvel de Instalao: Difcil
Requisitos de mquina: PC 486 DX100/66 MHz, 16 Mb de memria.
Caractersticas:
Primeiramente, antes de instalar o MRTG, necessrio ter um HD de boa
capacidade, devido aos logs que o MRTG gera, e aos grficos que so montados
utilizando arquivos no formato GIF.
O Multi Router Traffic Grapher MRTG uma ferramenta para monitorar o
trfego na rede, a utilizao de interfaces, links de redes, utilizao de CPU e qualquer
outra varivel numrica de equipamentos que suportem estas caractersticas de
gerenciamento.
Ele gera automaticamente pginas HTML com imagens GIF atualizadas em um
determinado perodo de tempo. Estas pginas representam os dados obtidos dos
dispositivos gerenciados. Um exemplo de grfico pode ser visto na figura abaixo:
Figura 33. Exemplo de grfico gerado pelo MRTG.
Baseado na linguagem Perl e C de fcil manipulao. aconselhvel ser usado

juntamente com um servidor WEB (exemplo: Apache) para facilitar as consultas aos
grficos de monitoramento. Utiliza o SNMP para ler as informaes dos dispositivos
gerenciados e programas escritos em linguagem C para montar os grficos. Estas
pginas geradas pelo MRTG podem ser consultadas de qualquer computador que possua
um browser instalado.
interessante utilizar o MRTG em conjunto com um outro software de
gerenciamento de redes, com suporte a SNMP, como o WhatsUP, citado anteriormente.
A coleta pontual, possibilidade de visualizao diria, semanal, mensal e anual das
estatsticas geradas nos grficos. Isto possvel pois o MRTG armazena os logs das
informaes dos equipamentos contendo a data destas.
O seu cdigo desenvolvido em Perl, e possui um programa (cfgmaker) para
63
gerao de arquivos de configurao onde especificado <comunidade>@<host ou

IP> e o identificador das variveis a serem coletadas.
Para gerar um grfico necessrio conhecer o OID (identificador do objeto) da
varivel que o agente responde. O MRTG no possui um limite de equipamentos para se
gerenciar, e pode monitorar qualquer varivel SNMP. As variveis mais usadas so: taxa
de utilizao do canal, utilizao dos modens e carga de CPU.
Para que o MRTG tenha um bom funcionamento necessrio que todos os
dispositivos que sero gerenciados tenham o agente SNMP habilitado. O servidor
MRTG precisa ter permisso de leitura das informaes de gerenciamento nestes
agentes.
Como o MRTG uma coleo de scripts escritos em Perl necessrio que se
tenha uma verso do interpretador de comandos Perl para a plataforma na qual se deseja
instalar o MRTG.
Na URL: http://roadrunner.ucpel.tche.br/mrtg/ pode-se observar a aplicao do
MRTG nos roteadores e Switchs do ambiente de gerenciamento.
3.3
Arquitetura Funcional do Ambiente de Gerenciamento
A Arquitetura Funcional do Ambiente Gerenciado permite observar-se o

funcionamento de todo o ambiente de gerenciamento. O diagrama do ambiente de
gerenciamento pode ser observado no Anexo 3.
3.4
Neste captulo, aps um estudo exaustivo do assunto e da reunio de diferentes

ferramentas de gerenciamento, escolheu-se algumas ferramentas utilizadas no
gerenciamento do ambiente. Tentou-se priorizar as chamadas ferramentas de domnio
pblico, mas infelizmente estas ferramentas no apresentam ainda um grau de qualidade
satisfatro, segundo os requisitos pr-estipulados nesta seo.
Ferramentas de gerncia so fundamentais para o perfeito funcionamento de
uma rede. Ferramentas desenvolvidas em SNMP aliam alta performace a grande
simplicidade, e constituem parte fundamental na administrao de qualquer rede de
computadores.
A caracterstica atual no mercado de softwares para gerenciamento a falta de
ferramentas que alm da simples monitorao sobre o estado operacional dos
equipamentos, gerem relatrios e grficos estatsticos histricos, tais como nmero
de horas/dias que determinado equipamento ficou com falha em sua comunicao
(grfico de disponibilidade), quantidade de bytes enviados/recebidos por determinada
interface de um equipamento levando-se em conta a capacidade desta interface (grfico
de largura de banda utilizada), ou seja, uma ferramenta de Gerncia de Nvel de
Servios - SLM. Nas pesquisas, foram encontrados menos de sete softwares especficos
para SLM, todos de grandes fabricantes de software e com custos na faixa dos U$
100.000,00, podendo facilmente chegar aos U$ 200.000,00 (de acordo com o nmero e
tecnologia dos equipamentos a serem gerenciados). Percebe-se que o mercado para os
fornecedores destas ferramentas so os grandes Provedores de Servios de rede, ficando
ento desassistidas as pequenas e mdias organizaes que hoje necessitam destas
informaes praticamente tanto quanto as grandes organizaes.
64
4 SLA - Service Level Agreement

Acordo de Nvel de Servio (Service Level Agreement - SLA), um contrato
entre uma Provedora de Servios (Service Provider) e o usurio destes servios. um
acordo, contratualmente garantido, que obriga os provedores a manterem um certo nvel
de qualidade do servio [6].
Com o mercado em fase de abertura e expanso, passa a existir a possibilidade
do aumento dos provedores de servio de comunicao entrarem e competirem pelos
consumidores. Estes novos provedores necessitam ganhar mercado e firmarem-se como
empresas srias e competitivas. SLAs so um meio de atrair consumidores e podem
contribuir para estabelecer uma imagem de credibilidade para estas novas empresas,
atravs do oferecimento de compensaes caso os servios garantidos no sejam
atingidos.
Segundo [30], Sem um entendimento claro a respeito de SLAs, Gerentes de
Redes correm o risco de pagarem muito, mas receberem pouco de um determinado
Provedor de Servios de rede. Sem um bem projetado SLA para oferecer, Provedores de
Servio correm o risco de perder clientes importantes, bem como de diferenciarem-se
dos concorrentes.
A rpida evoluo atual do mercado de telecomunicaes faz com que novos
servios sejam introduzidos e novas tecnologias de rede estejam disponveis. SLAs
podem encorajar consumidores a utilizarem estas novas tecnologias e servios, desde
que um certo nvel de performance seja garantido pelo provedor.
4.1
Gerenciamento de Nvel de Servio SLM
Segundo [30], o SLM seria um tipo de gerenciamento onde as atividades das

reas funcionais de gerenciamento de Performance e de Falha criam uma terceira
atividade (o SLM), integrando profundamente determinados aspectos de cada uma
destas reas funcionais:
Figura 34: Relao entre as reas Funcionais de Gerncia e SLM - Fonte:

[25].
O SLM ento seria esta nova rea das Provedoras de Servio especializada em
65
desenvolver, negociar e vender, implementar, executar e acompanhar o nvel de servio

garantido atravs dos SLAs [25].
4.2
Coexistncia entre SLA e QoS
QoS um amplo conceito envolvendo muitos parmetros de performance e

medidas. Pode ser definido como o resultado da performance do servio que determina
o grau de satisfao de um usurio com este servio [25].
A disponibilizao de relatrios de performance, foco deste trabalho, um dos
processos de Gerenciamento de QoS no Telecom Operations Map [27], e requisito
bsico para acompanhamento se os acordos de um SLA esto sendo cumpridos. Dentre
os diversos parmetros de QoS, provavelmente um ou mais destes parmetros iro
compor parte do contrato de SLA.
Atualmente, h uma nova nfase na especificao de QoS nos SLAs. Isto inclui a
abertura do mercado de telecomunicaes para a competitividade na proviso de
servios, a exploso nos negcios atravs da Internet (e-Business) que requerem altos
QoS da rede e os servios associados, como servidores, bancos de dados etc, e o
desenvolvimento e implementao de novos servios baseados em novas tecnologias
como ATM e IP. Estas tecnologias baseadas em clulas/pacotes criam novas questes de
QoS quando comparadas sobre os tradicionais servios baseados em circuitos em termos
de monitorao e anlise de dados de performance, e a interpretao destes dados em
relatrios de performance de QoS.
Portanto, o acordo nos termos e definies para os parmetros de QoS, suas
medidas e anlises de performance, so a chave para a construo e gerncia de SLAs
entre usurios e Provedores de Servios.
4.3
Abrangncia de SLAs nas Empresas
Na consulta Nmero de SLAs que sua empresa atualmente oferece ou

contratou, 56% dos entrevistados afirmaram possuir no mnimo um parmetro de SLA
atualmente em seu ambiente de trabalho (na pesquisa realizada no ano anterior este
nmero era 49%). A grande maioria possui entre 1 e 5 SLAs implementados, mas alguns
dos entrevistados afirmaram possuir mais de 10 SLAs em vigor. A mdia final ficou em
2,2 SLAs por empresa.
Ainda sobre esta consulta, mais da metade dos pesquisados esto planejando
implementar ou adicionar SLAs nos prximos seis meses. Aproximadamente 25% dos
pesquisados que no possuem SLAs em suas empresas atualmente esto trabalhando
para que no mnimo um SLA seja oferecido ou contratado nos prximos 6 meses.
Uma outra cnsulta realizada, refere-se aos parmetros de qualidade mais importantes.
De acordo com a pesquisa, Disponibilidade da Rede (Network Availability) e
Disponibilidade da Aplicao (Application Availability) so as duas mais importantes
medidas para a Gerncia de Nvel de Servio, de acordo com a pesquisa.
Muito prximos em importncia da Disponibilidade da Rede e Aplicao esto
os parmetros Performance da Rede (Network Performance) e Satisfao do Cliente
(Customer Satisfaction). Tempo de Resposta da Aplicao (Application response
time), em quinto lugar no ndice de importncia pesquisado, acima inclusive de Vazo
da Rede (Network Throughput), vem confirmar a importncia da performance das
aplicaes, como sendo o parmetro mais visvel para o usurio final da qualidade ou
no dos servios prestados:
66
Figura 35: Parmetros mais importantes de SLM Fonte: [30].
4.4
Requisitos
Para auxiliar no trabalho de levantamento de requisitos para construo de um

Acordo de Nvel de Servio (SLA), faz-se necessrio a aplicao de um questionrio
onde atravs dele levantar-se- os elementos que sero pontos de partida para realizao
do(s) SLA(s).
Aplicou-se dois questionrios na instituio - UCPel (um em cada ambiente de
gerenciamento), cujos resultados subsidiaram o encaminhamento do projeto.
Tendo-se como base o trabalho realizado pelo aluno de ps-graduao Jlio
Csar da Costa Ribas, as perguntas de ambos os questionrios so descritas abaixo.
67
UNIVERSIDADE CATLICA DE PELOTAS

Questionrio de Satisfao dos Usurios
POP UCPel
Caro Usurio...
Atravs deste questionrio iremos avaliar os nveis de servios prestados pelo
POP UCPel, verificando assim o grau de satisfao dos usurios de nossos
servios, visando melhorias futuras.
Sendo assim, pedimos sua especial ateno ao responder as perguntar abaixo.
-------------------------------------POP UCPel
--------/--------/-------Data
1. Qual a qualidade dos servios prestados pelos funcionrios da

instituio?
[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
2. Quando voc aciona o suporte tcnico, o tempo de resposta :

[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
3. Qual a qualidade dos servios prestados pelo suporte tcnico?

[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
68
4. Qual a qualidade dos servios prestados pela rea de Redes?

[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
5. O desempenho da rede :
[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
6. Como voc classifica a estabilidade da rede de dados?

[
[
[
[
[
] Pssimo
] Ruim
] Regular
] Bom
] timo
7. Voc est satisfeito com a disponibilidade dos servios na rede?

[ ] Sim
[ ] No
8. Voc considera a rede segura, quanto a questo de hackers?

[ ] Sim
[ ] No
69
9. A conexo discada (Internet), atende suas necessidades, no quesito

velocidade/desempenho?
[ ] Sim
[ ] No
10. Voc acha necessrio a criao de um programa de treinamento?

[ ] No
[ ] Sim
11. Voc acha necessrio a criao de algum outro servio?

[ ] No
[ ] Sim
No anexo 5 temos uma mdia das repostas dos usurios. A pesquisa foi
realizada com base na resposta de 30 usurios.
70
4.5
Fundamentos para Anlise e Medio
Esta etapa realiza-se com o objetivo de analisar a utilizao do recurso para

determinar a demanda futura ao sistema. A anlise do ambiente de gerenciamento
envolve a procura pela superutilizao de qualquer recurso de hardware / software que
causem reduo no desempenho do ambiente. Envolve tambm a procura do efeito
residual de gargalos: outros recursos de hardware que estejam sendo subutilizados.
4.5.1
Cargas de Trabalho
Antes que se possa definir as expectativas para um sistema,
necessrio conhecer o que est sendo solicitado a ele. Este
processo chamase caracterizao da carga de trabalho. Uma
unidade de carga de trabalho uma lista das solicitaes de
servio feitas ao sistema ou feitas a um recurso especfico do
sistema. So exemplos de unidades de carga de trabalho: o
nmero de tentativas de acesso a disco por segundo, o nmero de
bytes transferidos por segundo ou o processo de recebimento de
dados a partir de um servidor (o cliente enviando ao servidor, pela
rede, uma solicitao, o servidor respondendo ao cliente, pela
rede).
Determinar a caracterizao da carga de trabalho requer a
compreenso do que est acontecendo em um ambiente
especfico. Em um ambiente do servidor de arquivo e impresso, a
rea de maior interesse a E/S de disco ou o nmero de usurios
acessando um servidor, enquanto que, em um servidor de
aplicativos, a rea de maior interesse a quantidade de memria
que est sendo utilizada por um aplicativo. Isto no quer dizer que
a utilizao de memria no seja importante em um servidor de
arquivo e impresso; em vez disto, sensato concentrar-se no
dispositivo que tem maior chance de tomarse um gargalo do
sistema[37].
4.5.2
Utilizao do recurso
Para determinar se um recurso est sendo muito ou pouco utilizado, ou se est

em sua capacidade e desempenho mximos, primeiro devemos identificar o que
normal no ambiente. Cada ambiente nico, com diferentes fatores afetando o modo
como os recursos so utilizados ou consumidos.
Coletar e salvar dados em perodos de acesso normal ajuda a determinar se as
demandas de um recurso, no futuro, esto em nveis esperados (normais), abaixo da
expectativa ou muito acima do nvel normal. Para fazer isso, devemos executar sempre
os mesmos passos para coletar novamente os mesmos dados, comparando-os com os
dados da metodologia. Essa coleta contnua de dados , ento, utilizada para criar o
banco de dados de atividade de medio.
Para reduzir o volume de dados, devemos coletar os dados de anlise e
otimizao do servidor somente durante perodos de picos de atividade. A maioria dos
negcios tem um perodo de pico de atividade no meio da manh e no meio da tarde.
71
4.5.3
Parmetros para Gerenciamento
Para que algo possa ser analisado, conferido e gerenciado, necessrio que
existam fatores mensurveis dentro desta atividade. Assim sendo, vrios parmetros
para medir a qualidade em servios de rede foram sendo observados como os mais
relevantes e dentro de cada um destes parmetros valores so tidos como ideais,
tolerveis, indesejados etc. Tais parmetros sero discutidos ao longo deste
captulo.
Mas importante observar que tanto os parmetros analisados podem variar, de
acordo com o tipo de tecnologia que est sendo tratado, como os valores a serem
considerados dentro de cada um destes parmetros tambm iro variar de acordo com
vrios aspectos, tais como a qualidade de servio desejada e os meios fsicos
disponveis.
De acordo com Dalila Said da TVA [23], ainda falta uma padronizao dos
parmetros que estabeleam critrios de qualidade, e segundo o estudo sobre Acordo de
Nvel de Servio (SLA) do Telemanagement Frum [25], um nmero enorme de
parmetros de performance existe com nomes similares, mas com drsticas diferenas
em suas definies.
Para Marcionis Alves da Engeredes [1], os principais indicadores para
acompanhamento da qualidade dos servios de rede so: Latncia, Disponibilidade e
Tempo de Soluo de Falhas (ou Mean Time To Repair - MTTR). O indicador Taxa de
Erros um importante indicador para gerncia pr-ativa quando tratado ainda antes de
ter sido observado pelo usurio.
4.5.3.1 Categorizao dos Parmetros
Em primeiro lugar, importante entendermos que existem parmetros de
Qualidade de Servio (Quality of Service QoS) que so dependentes do tipo de
tecnologia utilizada ou servios oferecidos, assim como outros so genricos,
independentes do tipo de tecnologia ou servio.
4.5.3.1.1
Parmetros Independentes do Servio e Tecnologia
Parmetros independentes do servio e tecnologia so normalmente

especificados em SLAs. Independem de qualquer tipo de fator alm da prpria
competncia do Provedor em fornecer o servio comprometido [25]. Alguns exemplos
so:
9 Percentual de Disponibilidade: percentual indicando o tempo que o servio de
rede esteve disponvel para cumprir seus servios bsicos ao usurio.
9 Tempo para recuperao de falhas (Mean Time To Repair - MTTR): mdia de
tempo para o reparo de servios indisponveis.
9 Tempo para instalao do servio (Mean Time to Provide Service - MTPS):
mdia de tempo para instalao ou disponibilizao de um servio contratado.
Dentro desta categoria, inclusive parmetros indicando o nmero mximo de
tentativas para acionar a manuteno podem ser acertados entre as partes. Muitos destes
parmetros inclusive so os que normalmente as agncias reguladoras dos servios de
telecomunicaes utilizam para conferir a qualidade das Prestadoras de Servios para
com os seus clientes.
72
4.5.3.1.2
Parmetros Dependentes da Tecnologia
So aqueles relacionados com a tecnologia que suporta o servio oferecido pela

Prestadora. A deciso sobre qual destes parmetros sero inclusos no SLA pode ser uma
escolha individual para cada servio contratado. Estes parmetros precisam responder
pelas particularidades tcnicas de cada tecnologia. Alguns exemplos so [25]:
9 Camada Fsica: cabeamento de cobre ou fibra tica e transmisso terrestre,
rdio ou satelital iro interferir diretamente nos parmetros determinados para
Perda, Retransmisso e Latncia.
9 Camada ATM: perda e erro de clulas, intervalo e mdia de Peak Cell,
Maximum Burst Size, Maximum Cell Rate, Disponibilidade, Throughput e
Utilizao.
9 Camada IP: pacotes perdidos ou com erro, latncia na transferncia dos
pacotes, Disponibilidade e Utilizao.
4.5.3.2 Parmetros mais Comuns em Redes IP
Para o escopo deste trabalho, os parmetros de avaliao de redes IP so os mais
relevantes. A seguir teremos a definio dos principais parmetros para este tipo de rede
[6]:
9 Latncia: o tempo que um pacote IP leva para ir e voltar (round-trip) de um
ponto a outro da rede. normalmente medida em milissegundos. Quanto menor
a latncia, melhor o tempo de resposta da rede.
9 Perda de pacotes: o ndice que mede a taxa de sucesso na transmisso de
pacotes IP entre dois pontos da rede. normalmente exibida como uma
porcentagem, indicando o percentual de pacotes perdidos. Quanto menor a perda
de pacote, maior a eficincia da rede.
9 Erros: relao do nmero de pacotes cujo contedo (bits) contm erros
(detectados pelos mecanismos de verificao de integridade de transmisso). Os
erros podem ser causados por alguma falha nos meios de transmisso, falha ou
sobrecarga em algum dos equipamentos e normalmente so medidos tambm
como uma porcentagem do total da transmisso dentro de um determinado
perodo. A taxa de erros em um servio de rede um parmetro de fundamental
importncia na gerncia, pois de difcil deteco (no se detecta to claramente
como uma queda no servio ou a alta latncia), e pode ser a causadora de muitos
problemas que sero detectados nos demais fatores.
9 Disponibilidade da Rede: o ndice que mede o tempo que uma rede esteve
operacional para transmisso e recepo de dados. normalmente registrada
como uma porcentagem, indicando o percentual de tempo em que a rede esteve
no ar. Quanto maior a disponibilidade, maior a confiabilidade da rede.
Para exemplificar, abaixo temos um clculo onde pode ser observado o nmero
de dias, horas e minutos, que um servio de rede poder ficar sem servio (down) de
acordo com o ndice de disponibilidade comprometido no SLA. Este SLA considera que
o servio de rede deveria estar disponvel durante as 24 horas, 7 dias por semana,
durante os 365 dias do ano (24x7x365) [26]:
73
Disponibilidade
Sem servio por ano (24x7x365)
99.000%
3 dias,
15 horas,
36 minutos
99.500%
1 dia,
19 horas,
48 minutos
99.900%
8 horas,
46 minutos
99.950%
4 horas,
23 minutos
99.990%
53 minutos
99.999%
5 minutos
Tabela 6. ndices de disponibilidade da rede Fonte: [26].
Como pode ser observado na tabela acima, se um cliente contratou, por exemplo,
um Acordo de Nvel de Servio de disponibilidade de 99.990% (quatro noves como
conhecido no jargo tcnico), o limite de interrupes (queda no servio) na conexo de
rede contratada, durante todo o perodo de um ano, de 53 minutos. Acima disto, a
penalidade prevista no contrato poder ser cobrada pelo usurio.
4.5.3.2.1
Avaliao dos Parmetros Disponibilidade e Performance
Apesar de Performance da Aplicao ser um fator considerado como dos mais

importantes, as principais mtricas para definir e mensurar a disponibilidade e
performance da rede acaba sendo sobre os dispositivos e enlaces (devices e links)
conectados rede e a disponibilidade dos servidores de rede (availability of servers).
Entretanto, 62% dos pesquisados avaliam a disponibilidade das aplicaes na rede e
45% avaliam o tempo de resposta durante perodos de pico como forma de medir a
disponibilidade e performance da rede.
Como no poderia deixar de ser, outro parmetro muito lembrado foi Latncia
da Rede (network round trip delay) com 62% dos entrevistados indicando-o como um
dos principais parmetros para medio da disponibilidade e performance de uma rede.
4.5.3.2.1.1 Disponibilidade
De acordo com [25], o parmetro Disponibilidade (Availability) provavelmente

seja o mais significativo indicador de QoS/SLM em qualquer tipo de servio. Ele
depende de um conjunto de aspectos combinados, que resultam em um resultado final
de servio disponvel de um item, e pode referir-se a qualquer parte da rede, tanto em
nvel de hardware como de software. Disponibilidade de uma rede, tipicamente pode
ser expressa atravs das seguintes frmulas:
74
Parmetro
Frmula
Unidade
Exemplo
Disponibilidade
up times 100
up times + down times
(%)
99.9%
Indisponibilidade
down times 100

up times + down times
(%)
0.1%
Tempo acumulado
de Indisponibilidade
(horas)
8.76 horas
down times acumulados durante

um perodo de tempo
em um ano
Tabela 7: Clculos de Disponibilidade Fonte: [25].

4.5.3.2.1.2 Disponibilidade via SNMP
Esta forma mais refinada de teste de disponibilidade em gerenciamento de

redes. Para calcular a disponibilidade de uma interface atravs de SNMP, so utilizadas
as variveis ifOperStatus e ifLastChange da MIB-II .
Figura 36: Verificao da Disponibilidade via SNMP e MIB-II.
O diagrama acima mostra o clculo de disponibilidade de uma interface:

9 As 11:10 a verificao (polling) detectou que a interface estava indisponvel
(down).
9 Como o valor da varivel ifLastChange estava em 2 minutos, foi assumido que a
interface estava indisponvel h 2 minutos atrs.
9 As 11:15 a verificao detectou que a interface operava normalmente.
9 Novamente leu o valor da varivel ifLastChange que desta vez estava em 3
minutos, concluindo ento que a interface esteve indisponvel das 11:08 s
11:12, ou seja, foram 4 minutos fora de servio.
75
4.5.3.2.1.3 Disponibilidade via Ping Alcanabilidade
Detecta quando um ping direcionado um elemento no obtm retorno. Este

elemento pode estar com falha e o elemento testado esteja com falha ou alta taxa de
atraso.
Este relatrio til para testar a Disponibilidade de elementos que, por no
estarem diretamente ligados ao backbone (por exemplo: as demais interfaces de um
roteador no a que o interconecta rede principal), no teriam seu status das variveis
ifOperStatus e ifLastChange alterados quando da queda da comunicao na interface do
roteador que o liga rede principal. Neste caso, todas as demais redes ligadas a este
roteador estariam sem comunicao com o mundo exterior, mas suas interfaces estariam
com status de up (pois foi somente uma interface que teve seu status alterado para
down). Dessa forma, um relatrio como o Disponibilidade via SNMP destas
interfaces, que muitas vezes ser o indicador da disponibilidade de toda a rede nelas
conectadas, no estaria condizente com a realidade, pois apesar destas interfaces no
terem ficado com status de down, perderam a comunicao devido a falha da interface
principal deste equipamento.
Sendo assim, o relatrio Disponibilidade via SNMP acusaria 100% de
disponibilidade para as interfaces das redes X,Y e Z mesmo no perodo no qual a
interface principal esteve down, pois no momento que esta restabelecesse a
comunicao, a varivel ifLastChange das demais interfaces teriam seus valores
testados e nada seria acusado, representando ento, para a estao Gerente, que
estiveram up (o que realmente verdade) durante todo o perodo.
4.5.3.3 Largura de Banda Utilizada
Largura de banda utilizada uma das estatsticas de Performance mais utilizada
em gerenciamento da capacidade da rede bem como para a soluo de problemas. A
seguir, temos as frmulas utilizadas para o clculo desta informao [22]:
Utilizao (in) =
Utilizao (out ) =
ifInOctets 8
ifSpeed t
ifOutOctets 8
ifSpeed t
Utilizao (total ) =
Utilizao (in) + Utilizao (out )

2
Para linhas full-duplex, o clculo de utilizao total de fato a mdia da

utilizao das duas direes de trfego. Em outras palavras, se a Utilizao (in) de 40
% e a Utilizao (out) 60 %, ento a Utilizao (total) de 50 %. Por outro lado, o
trfego total de um elemento realmente a soma do trfego das duas direes.
4.5.3.4 Erros por Interface
Erros por Interface um relatrio importantssimo para deteco de,

principalmente, falhas ou rudo nos meios de transmisso. Em situaes onde este tipo
76
de informao torna-se necessria, este relatrio indica o percentual de pacotes com

erros do total de pacotes recebidos ou enviados.
Certamente, o percentual de pacotes recebido (in) o mais relevante, em virtude
que normalmente este tipo de erro ser encontrado na recepo dos dados e no no
envio. As frmulas so muito semelhantes s anteriores, apenas com a bvia mudana
das variveis envolvidas e que este clculo, devido justamente ao tipo de informao
disponvel na MIB-II, feito levando-se em conta os pacotes IP e no os bytes de dados
enviados ou recebidos [22]:
Erros (in) =
ifInErrors
ifInUcastPkts + ifInNUcastPkts
Erros (out ) =
ifOutErrors
ifOutUcastPkts + ifOutNUcastPkts
Porcentagem
erros de entrada
de
Porcentagem
erros de sada
de
Este relatrio no possui um terceiro grfico indicando o total de erros,

somando ou fazendo a mdia entre os erros de entrada e de sada. Isto se deve ao motivo
de que o relevante nestes casos justamente descobrir se, caso estejam acontecendo
erros, estes so no recebimento dos pacotes (a grande maioria dos casos) ou no envio e
finalmente o percentual desta taxa de erros.
Os objetos IfOutOctets e ifOutDiscards juntos podem sinalizar um
congestionamento da rede, isto caso ocorra um aumento do valor de ifOutDiscards
devido ao descarte de muitos pacotes que tenham que deixar a interface, e uma
diminuio do nmero total de bytes de sada, indicado pelo objeto IfOutOctets.
Atravs do objeto IfInUnknownProtos pode-se ter informaes do nmero de
descartes ocorridos devido ao recebimento de pacotes de protocolos desconhecidos,
portanto, caso o valor dos objetos IfInUnknownProtos e IfInDiscards estiverem
crescendo proporcionalmente no h deteco de nenhum problema.
O objeto IfOutlen indica se o dispositivo est tendo problemas para enviar dados
para fora, seu valor aumenta de acordo com o aumento do nmero de pacotes
aguardando para deixar a interface.
Para calcular-se a taxa de utilizao de uma detreminada interface, pode-se
utilizar as seguintes formulas, uma aps a outra at chegar no final:
9 Total de bytes que trafegam na porta em determinado perodo:
Total Bytes = InOctets + OutOctets
9 Total de bytes por segundo:
Total de Bytes/segundo =Total de Bytes / tempo_amostra_segundo
9 Total de bits por segundo:
Total de bits/segundo = Total de bytes x 8
9 Taxa de utilizao:
Total de bits/segundo / ifSpeed
Caso queira-se o valor em Mbps, divide-se por 1024.
4.5.3.5 Necessidades do Mercado
Entre 01 de Junho e 03 de Julho de 2000, a empresa Lucent Technologies

realizou uma pesquisa sobre SLA para o mercado de gerenciamento de redes atravs de
77
sua pgina Web [30]. Dentre as concluses obtidas, podemos destacar:

9 O parmetro Disponibilidade da Rede , em todas as avaliaes, o parmetro
mais importante dentro de um gerenciamento de nvel de servios.
9 A satisfao com as ferramentas de auxlio ao Gerenciamento de Nvel de
Servios, que de 1998 para 1999 havia aumentado, retrocedeu na pesquisa
realizada no ano 2000.
9 A preocupao com a medio de performance das aplicaes corporativas tem
crescido na mesma proporo que o mercado de comrcio eletrnico e outras
aplicaes fortemente baseadas em rede tem crescido e ocupado cada dia mais a
largura de banda de rede disponvel.
9 Gerentes de Rede desejam ferramentas que os auxiliem a trabalhar de forma prativa.
9 Necessidade de ferramentas de Gerenciamento de Nvel de Servio que
permitam de uma forma clara e simplificada, definir, medir e monitorar a
performance da rede e das aplicaes baseadas em rede.
9 Apesar de inicialmente parecer uma nova tarefa para os gerentes de rede, a
incluso de um SLA pode ser usado para definir claramente as expectativas
(tanto dos usurios quanto dos responsveis pelo servio) e assegurar que um
nvel de servio seja disponibilizado.
9 Um empecilho citado foi a falta de mo-de-obra especializada no assunto de
gerenciamento de redes e tambm com uma viso ampla a respeito da indstria
da comunicao.
4.5.3.6 Periodicidade da Emisso dos Relatrios de SLA
Para verificao dos vrios elementos de um SLA, relatrios de status e atividade

precisam ser gerados automaticamente ou manualmente pelo operador da ferramenta de
SLM. Na pesquisa, foi verificado que a base de relatrios sobre a situao diria,
semanal e mensal de cada parmetro do SLA so os mais requisitados pelos
gerentes de rede, tanto nas emisses automatizadas de relatrio, quanto nas executadas
manualmente.
De acordo com a pesquisa, a tendncia que a emisso de relatrios seja
baseada em perodos de tempo maiores na medida em que a confiana nos servios
contratados aumente, bem como na prpria ferramenta de auxlio gerncia:
78
Figura 37: Freqncia da emisso de relatrios Fonte: [30].
4.5.3.7 Aes baseadas em limites atingidos thresholds: o controle efetivo do

SLA
Um monitoramento muito importante a deteco automtica de limites

(thresholds) para determinados valores.
Pode-se configurar, por exemplo, um percentual mximo de erros por elemento
ou de largura de banda utilizada. Assim que determinado elemento atingir o valor
configurado como mximo (ou mnimo) para esta monitorao, uma ao poder ser
automaticamente executada pelo gerente. Uma trap, um e-mail para o administrador do
sistema e/ou do elemento e at mesmo a execuo de alguma rotina pr-configurada
pelo usurio.
Esta uma caracterstica de vital importncia em um gerente.
4.5.3.8 Metodologia de Medio
Este tpico enfatiza a importncia de implementar uma
metodologia de medio de informaes para utilizao na anlise de
dados de desempenho.
Como deve ser estabelecida uma metodologia antes de se
analisar o desempenho do sistema, este mdulo focaliza a criao de
uma metodologia de medio e identifica um processo de coleta e
utilizao de dados do sistema [37].
As ferramentas descritas no captulo 3 foram utilizadas para coletar dados e criar
uma metodologia de medio.
79
4.5.3.8.1
Obteno dos Dados
Para determinar o grau de utilizao de um determinado recurso, ou, sua

capacidade e desempenho mximos, primeiro deve-se identificar o que normal no
ambiente. Cada ambiente nico, com diferentes fatores afetando o modo como os
recursos so utilizados ou consumidos [37]. Para chegar a este nvel considerado normal
no ambiente gerenciado, deve-se comear com uma coleta de dados em perodos
variados, priorizando-se aqueles considerados de pico.
Atravs desta base de dados, pode-se futuramente identificar o desempenho de
um recurso, classificando este como normal, abaixo das expectativas ou acima das
espectativas.
Com base nestas informaes da base de dados pode-se tomar as medidas
necessria, podendo estas variarem desde a no realizao de ajuste algum, j que o
desempenho esta normal, ou seja, dentro do esperado; pode-se realizar uma
distribuio/descentralizao de servios ou de usurios centrados em um servidor,
passando estes para um outro no to utilizado; ou a aquisio de novos equipamentos
afim de resolver o eventual problema.
4.5.3.8.2
Automatizao da Coleta de Dados
A fim de facilitar a anlise dos dados coletados durante um determinado perodo,

faz-se necessrio automatizao da coleta dos dados de informaes.
Segundo [37], a coleta dos dados pode-ser centralizada ou no. A monitorao
centralizada permite que os dados de vrios computadores sejam armazenados em um
nico arquivo de log, mas aumenta o trfego da rede durante as horas de produo. A
monitorao descentralizada cria mais trfego de disco em cada computador
monitorado.
No escopo de trabalho em questo optou-se por realizar uma coleta centralizada.
Esta coleta ser realizada pelo Gerente (Mercurio) com o auxlio das ferramentas
descritas no captulo 3. Na seo 4.6, pode-se observar com maior clareza a
metodologia utilizada na coleta dos dados.
importante salientar que a coleta centralizada til para um nmero
relativamente pequeno de dispositivos monitorados. Sendo este nmero em torno de 25
dispositivos.
4.5.3.9 Variveis monitoradas no SLA
Sem dvida que entre as variveis de MIB mais importantes esto as da MIB-II.
Presentes em praticamente todos os equipamentos gerenciveis por SNMP, possvel
gerenciar inmeros fatores com as informaes obtidas atravs da coletas dos valores
destas variveis.
O critrio para selecionar quais variveis so utilizadas na monitorao de cada
elemento, baseado no tipo de rea Funcional de gerncia (Falha, Performance,
Contabilizao, Configurao e Segurana) escolhido pelo administrador do sistema
para cada elemento a ser gerenciado. Certamente existiro casos em que determinada
rea Funcional de gerncia no interessar para determinado elemento. Em casos deste
tipo, bastar no selecionar esta gerncia.
Por hora, o principal a entender so os campos varivel, configurao, falha,
performance, contabilizao e segurana. O campo varivel do tipo String e serve para
80
armazenar o nome da varivel (descrita em sua sintaxe exatamente como na RFC onde
foi publicada e respectivamente como ser encontrada na MIB dos equipamentos). J os
demais campos so do tipo Boolean (Yes / Not) e servem para indicar se a varivel
atende ou no cada uma das cinco reas funcionais de gerncia representadas por estes
campos.
Abaixo temos a relao completa de todas as variveis da MIB-II [7] organizada
por rea funcional atendida.
Gerenciamento de Configurao
Grupo
Varivel
System sysDescr
sysLocation
sysContact
sysName
Acesso
ro
rw
rw
rw
Interfaces ifDescr
ifType
ro
ro
ifMtu
ifSpeed
ro
ro
ifAdminStatus
ipFowarding
rw
rw
IP
Tipo
Informao
octet string Descrio do sistema
octet string Localizao fsica do sistema
octet string Pessoa responsvel pelo sistema
octet string Nome do sistema
octet string Nome da interface

integer Tipo de interface
Tamanho Maximo do datagrama
integer suportado pela interface
unsigned32 Largura de banda da interface
Indica se a interface esta
administrativamente
integer (up/down/test)
integer Se o dispositivo setado para IP
ipAddrTable
ipAdEntAddr
ipAdEntIfIndex
ro
ro
ipAddress
integer
ipAdEntNetMask
ro
ipAddress
ipAdEntBcastAddr
ipRoutTable
ipRouteDest
ipRouteIfIndex
ipRouteMetric1
ipRouteMetric2
ipRouteMetric3
ipRouteMetric4
ipRouteMetric5
ro
integer
rw
rw
rw
rw
rw
rw
rw
ipAddress
integer
integer
integer
integer
integer
integer
ipRouteNextHop
rw
ipAddress
ipRouteType
ipRouteProto
rw
ro
integer
integer
Endereos IP do dispositivo
O endereco IP desta entrada
Nmero da interface
Mascara de sub-rede para
enderecos IP
o bit menos significativo do
endereco IP de broadcast
Tabela de roteamento IP
Endereo IP do destino
Nmero da interface
Mtrica de roteamento #1
Prxima escala (endereco IP do
roteador, usado para roteamento
indireto)
Tipo
(indireto,
direto,valido,invalido)
Mecanismo
usado
para
81
TCP
UDP
EGP
ipRouteAge
rw
ipRouteMask
rw
ipRouteInfo
ro
tcpRtoAlgorithm
ro
tcpRtoMin
ro
tcpRtoMax
ro
tcpMaxConn
ro
tcpCurrEstab
ro
udpTable
udpLocalAddress
udpLocalPort
ro
ro
egpNeightState
egpNeighAddr
ro
ro
determinar a rota
Idade da rota em segundos
Mascara
da
subrede
para
ipAddress roteamento
Ponteiro MIB para um segundo
object protocolo
de
roteamento
identifier especifico
integer
Algoritmo
utilizado
para
determinar o "time-out" de
retransmisso de octetos TCP no
integer confirmados
Valor mnimo permitido para o
"time-out" de retransmisso TCP
integer em milisegundos
Valor mximo permitido para o
"time-out" de retransmisso TCP,
integer em milisegundos.
Limite de conexes que podem
ser abertas pela entidade de
integer transporte do dispositivo
Nmero
de
conexes
de
unsigned32 transporte corretamente abertas
Tabela de portas UDP recebendo
datagramas correntemente
ipAddress Endereo IP local
integer Porta UDP local
integer Estado de cada vizinho EGP

ipAddress Endereo IP do vizinho EGP
Sistema autnomo do vizinho
egpNeighAs
ro
integer EGP
Intervalo entre retransmisses de
egpNeighIntervalHello
ro
integer comandos Hello
Intervalo entre retransmisses de
egpNeighIntervalPoll
ro
integer comandos Poll
Modo de polling destas entidades
egpNeighMode
ro
integer EGP
Permite iniciar ou finalizar uma
egpNeighEventTrigger
rw
integer comunicao
egpAs
ro
integer Sistema autnomo local
Indica se o agente SNMP pode
SNMP snmpEnableAuthenTraps rw
integer enviar traps
Gerenciamento de Falhas
Grupo
Varivel
System sysObjectID
Acesso
ro
Tipo
Informao
object
identifier Fabricante do sistema
82
sysServices
ro
sysUpTime
ro
Interfaces ifAdminStatus
IP
EGP
rw
ifOperStatus
ro
ifLastChange
ipRoutTable
ipRouteDest
ipRouteIfIndex
ipRouteMetric1
ipRouteMetric2
ipRouteMetric3
ipRouteMetric4
ipRouteMetric5
ro
rw
rw
rw
rw
rw
rw
rw
ipRouteNextHop
rw
ipRouteType
rw
ipRouteProto
ipRouteAge
ro
rw
ipRouteMask
rw
ipRouteInfo
ro
ipNextToMediaTable
ipNetToMediaIfIndex
ipNetToMediaPhysAddre
ss
ipNetToMediaNetAddress
rw
rw
ipNetToMediaType
egpNeighState
rw
ro
egpNeighStateUps
ro
egpNeighStateDows
ro
SNMP snmpInASNParseErrs
rw
ro
Qual camada de protocolo o

sistema serve
Quanto tempo o sistema est
Time-Ticks operacional
Indica se a interface esta
administrativamente
integer (up/down/test)
Indica o status operacional da
integer interface (up/down/test)
Indica quando a interface mudou
time ticks seu estado operacional
Tabela de roteamento IP
ipAddress Endereo IP do destino
integer Nmero da interface
integer Mtrica de roteamento #1
Prxima escala (endereco IP do
roteador, usado para roteamento
ipAddress indireto).
Tipo (indireto, direto, vlido,
integer invalido)
Mecanismo
usado
para
integer determinar a rota
integer Idade da rota em segundos
Mascara
da
subrede
para
ipAddress roteamento
Ponteiro MIB para um segundo
object protocolo
de
roteamento
identifier especifico
Tabela de converso de endereos
IP
integer Nmero da interface
octect Endereo
do
meio
do
string mapeamento
ipAddress Endereo IP do mapeamento
Como
o
mapeamento
foi
determinado (outro, invlido,
integer dinamico, estatico)
integer Estado de cada vizinho EGP
Nmero de vezes que um vizinho
counter32 EGP entrou no estado up
Nmero de vezes que um vizinho
counter32 EGP entrou no estado down
Total de mensagens recebidas
counter32 com erros ASN
integer
83

counter32 com erros "too big"
snmpInNoSuchNames
ro
counter32 com erros "noSuchName"
snmpInBadValues
ro
counter32 com erros "badValue"
snmpInReadOnlys
ro
counter32 com erros "readOnly"
snmpInGenErrs
ro
counter32 com erros "genErr"
Total de mensagens enviadas com
snmpOutTooBigs
ro
counter32 erros "too big"
snmpOutNoSuchNames
ro
counter32 erros "noSuchName"
snmpOutGenErrs
ro
counter32 erros "genErr"
Gerenciamento de Performance
snmpInTooBigs
Grupo Varivel
Interfaces ifInDiscards
ifOutDiscards
ifInErrors
ifOutErrors
ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts
IP
ro
Acesso
ro
ro
ro
ro
ro
ro
ro
ro
ifInNUcastPkts
ro
ifOutNUcastPkts
ro
ifInUnknownProtos
ifOutQLen
ro
ro
ipInReceives
ro
ipInHdrErrors
ro
ipInAddrErrors
ipForwDatagrams
ro
ro
ipInUnknownProtos
ro
ipInDiscards
ro
ipInDelivers
ipOutRequests
ro
ro
Tipo
counter32
counter32
counter32
counter32
counter32
counter32
counter32
counter32
Informao
Taxa de descartes de entrada
Taxa de descartes de saida
Taxa de erros de entrada
Taxa de erros de saida
Taxa de bytes recebidos
Taxa de bytes enviados
Taxa de pacotes unicast recebidos
Taxa de pacotes unicast enviados
Taxa de pacotes no-unicast
counter32 recebidos
counter32 enviados
Taxa de pacotes de protocolos
counter32 desconhecidos recebidos
unsigned32 Total de pacotes na fila de saida
counter32 Taxa de datagramas de recebidos

Taxa de erros de cabealho de
counter32 entrada
Taxa de erros de endereco de
counter32 entrada
counter32 Taxa de datagramas repassados
Taxa de datagramas de entrada
counter32 para um protocolo desconhecido
counter32 descartados
counter32 entregues com sucesso
counter32 Taxa de datagramas de saida (no
84
ipOutDiscards
ro
counter32
ipOutNoRoutes
ro
counter32
ipRoutingDiscards
ro
counter32
ipReasmReqds
ro
counter32
ipReasmOKs
ro
counter32
ipReasmFails
ro
counter32
ipFragOKs
ipFragCreates
ro
ro
counter32
counter32
ICMP icmpInMsgs
icmpInErrors
ro
ro
counter32
counter32
icmpInDestUnreachs
ro
counter32
icmpInTimeExcds
ro
counter32
icmpInParmProbs
ro
counter32
icmpInSrcQuenchs
ro
counter32
icmpRedirects
ro
counter32
icmpInEchos
ro
counter32
icmpInEchoReps
ro
counter32
icmpInTimestamps
ro
counter32
icmpInTimestampReps
ro
counter32
icmpInAddrMasks
ro
counter32
icmpInAddrMaskReps
icmpOutMsgs
icmpOutErrors
ro
ro
ro
counter32
counter32
counter32
icmpOutDestUnreachs
icmpOutTimeExcds
ro
ro
counter32
counter32
inclui os datagramas repassados)

Taxa de datagramas de saida
descartados
Taxa de descartes ocorridos por
falta de informao de roteamento
Taxa de entradas de roteamento
descartadas
Taxa de datagramas recebidos
necessitando de remontagem
Taxa de datagramas com sucesso
na remontagem
Taxa de datagramas com falhas
na remontagem
Taxa
de
datagramas
com
insucesso na fragmentao
Taxa de fragmentos gerados
Taxa
de
recebimento
de
mensagens
Taxa de erros de entrada
Taxa de mensagens de Destino
no Alcanado recebidas
Taxa de mensagens de Tempo
Excedido recebidas
Taxa de mensagens de Problemas
com Parmetros recebidos
Taxa de mensagens de Fonte
Apagada recebidas
Taxa
de
mensagens
de
redirecionamento recebidas
Taxa de mensagens de Ecos
(requisio) recebidas
Taxa de mensagens de Respostas
a Eco recebidas
Taxa de mensagens de requisio
de timestamp recebidas
Taxa de mensagens de respostas
ao
pedido
de
timestamps
recebidas
Taxa de mensagens de Requisio
de Mscaras de Endereos
recebidas
Taxa de mensagens de Resposta a
Mscaras de Endereos recebidas
Taxa de sada de mensagens
Taxa de erros de saida
Taxa de mensagens de Destino
no Alcanado enviadas
Taxa de mensagens de Tempo
85
TCP
UDP
EGP
icmpOutParmProbs
ro
counter32
icmpOutSrcQuenchs
ro
counter32
icmpOutRedirects
ro
counter32
icmpOutEchos
ro
counter32
icmpOutEchoReps
ro
counter32
icmpOutTimestamps
ro
counter32
icmpOutTimestampsReps
ro
counter32
icmpOutAddrMasks
ro
counter32
icmpOutAddrMaskReps
ro
counter32
tcpAttemptFails
ro
counter32
tcpEstabResets
ro
counter32
tcpRetransSegs
tcpInErrs
ro
ro
counter32
counter32
tcpOutRsts
ro
counter32
tcpInSegs
tcpOutSegs
udpInDatagrams
udpOutDatagrams
udpNoPorts
ro
ro
ro
ro
ro
counter32
counter32
counter32
counter32
counter32
udpInErrors
egpInMsgs
ro
ro
counter32
counter32
egpInErrors
egpOutMsgs
ro
ro
counter32
counter32
egpOutErrors
ro
counter32
egpNeighInMsgs
ro
counter32
egpNeighInErrs
ro
counter32
Excedido enviadas
Taxa de mensagens de Problema
com Parmetros enviados
Taxa de mensagens de Origem
Apagada enviadas
Taxa
de
mensagens
de
redirecionamento enviadas
Taxa de mensagens de Eco
(requisio) enviadas
Taxa de mensagens Respostas de
Eco enviadas
Taxa de mensagens de requisio
de
Timestamp
requisies
enviadas
Taxa de mensagens de respostas
ao pedido de Timestamp enviadas
Taxa de mensagens de Requisio
de Mscara de Endereos
enviadas
Taxa de mensagens de Resposta
de Mscara de endereos enviadas
Nmero de tentativas de conexes
falhadas
Nmero de reinicializaes de
conexes estabelecidas
Nmero
de
segmentos
retransmitidos
Nmero de pacotes recebidos
Nmero de vezes que a entidade
tentou reinicializar uma conexo
Taxa
de
segmentos
TCP
recebidos
Taxa de segmentos TCP enviados
Taxa de datagramas recebidos
Taxa de datagramas enviados
Taxa de datagramas enviados
Taxa de datagramas UDP
recebidos com erro
Taxa de mensagens recebidas
comerro
Taxa de mensagens enviadas
Taxa de mensagens no enviadas
devido a ocorrencia de erros
deste vizinho EGP
com erro deste vizinho EGP
86
egpNeighOutMsgs
ro
egpNeighOutErrs
ro
egpNeighInErrMsgs
ro
egpNeighOutErrMsgs
ro
Taxa de mensagens enviadas a

counter32 este vizinho EGP
Taxa de mensagens no enviadas
counter32 e este vizinho EGP
Taxa de mensagens de erro
counter32 recebidas deste vizinho EGP
Taxa de mensagens de erro
counter32 enviadas a este vizinho EGP
SNMP snmpInPkts
snmpOutPkts
ro
ro
counter32 Taxa de pacotes SNMP recebidos

counter32 Taxa de pacotes SNMP enviados
taxa de Get/Get-Next-Requests
snmpInTotalReqVars
ro
counter32 enviados
snmpInTotalSetVars
ro
counter32 Taxa de Set-Requests recebidas
snmpInGetResquests
ro
counter32 Taxa de Get-Reuquests recebidas
Taxa
de
Get-Next-Reuqests
snmpInGetNexts
ro
counter32 recebidas
snmpInSetRequests
ro
counter32 Taxa de Set-Requests recebidas
snmpInGetResponses
ro
counter32 Taxa de Get-Responses recebidas
snmpInTraps
ro
counter32 Taxa de Traps recebidas
snmpOutGetRequests
ro
counter32 Taxa de Get-Reuquests enviadas
Taxa
de
Get-Next-Reuqests
snmpOutGetNexts
ro
counter32 enviadas
snmpOutSetRequests
ro
counter32 Taxa de Set-Requests enviadas
snmpOutResponses
ro
counter32 Taxa de Get-Responses enviadas
snmpOutTraps
ro
counter32 Taxa de Traps enviadas
Gerenciamento de Contabilizao
Grupo Varivel
Interfaces ifInOctets
ifOutOctets
ifInUcastPkts
ifOutUcastPkts
Acesso
ro
ro
ro
ro
Tipo
counter32
counter32
counter32
counter32
ifInNUcastPkts
ro
counter32
ifOutNUcastPkts
ipOutRequests
ipInReceives
ro
ro
ro
counter32
counter32
counter32
ipInDelivers
ro
counter32
tcpActiveOpens
ro
counter32
tcpPassiveOpens
ro
counter32
tcpInSegs
ro
counter32
IP
TCP
Informao
Taxa de bytes recebidos
Taxa de bytes enviados
Taxa de pacotes unicast recebidos
Taxa de pacotes unicast enviados
recebidos
enviados
Nmero de pacotes IP enviados
Nmero de pacotes IP recebidos
Nmero de pacotes IP de entrada
entregues com sucesso
Nmero de vezes que o sistema
abriu uma conexo
Nmero de vezes que o sistema
recebeu um pedio de abertura de
conexo
Nmero total de segmentos TCP
recebidos
87
UDP
tcpOutSegs
ro
tcpConnTable
tcpConnState
tcpConnLocalAddress
tcpConnLocalPort
tcpConnRemAddress
tcpConnRemPort
rw
ro
ro
ro
ro
udpDatagrams
ro
udpOutDatagrams
ro
udpTable
udpLocalAddress
udpLocalPort
ro
ro
SNMP snmpInPkts
snmpOutPkts
snmpInTraps
snmpOutTraps
Grupo
Nmero total de segmentos TCP

counter32 emitidos
Tabela
das
conxes
TCP
correntes
integer Estado da conexo
ipAddress Endereo TCP local
integer endereo IP local
ipAddress endereo TCP remoto
integer Endereo IP remoto
Nmero total de datagramas UDP
counter32 recebidos
Nmero total de datagramas UDP
counter32 enviados
Portas
UDP
recebendo
ro
counter32 Taxa de pacotes SNMP recebidos
ro
counter32 Taxa de pacotes SNMP enviados
ro
counter32 Taxa de traps recebidas
ro
counter32 Taxa de traps enviadas
Gerenciamento de Segurana
Varivel
Acesso
UDP udpTable
udpLocalAddress
udpLocalPort
snmpInBadCommunityNa
SNMP mes
snmpInBadCommunityUse
s
ro
ro
ro
ro
Tipo
Informao
Portas
UDP
recebendo
Total de pacotes com uma

counter32 community string incorreta
Total de pacotes com community
string que no permite a operao
counter32 requisitada
Tabela 8. Organizao das variveis MIB-II

4.5.3.9.1
Metas de Tempo de Resposta
Como descrito nas sees anteriores, um SLA composto por mtricas, que
cabem ser garantidas pela prestadora de servios ou pela Gerncia de Tecnologia de
Informaes.
De acordo com o SLA firmado entre as partes Mateus Casanova Pereira e
Universidade Catlica de Pelotas, definiu-se algumas mtricas que devem ser
garantidas pela prestadora, neste caso, representada por Mateus Casanova Pereira. Estas
mtricas sero cumpridas no horrio de expediente, sendo este das: 7:30 s 22:45.
As metas de tempo de resposta, que devero ser garantidas pela Gerncia de
Tecnologia de Informaes, so listadas na tabela abaixo. Alguns parmteros desta
tabela foram extrados de [37]:
88
Servios/Sporte
Suporte
Ordem de Servio
Software
Ordem de Servio
Servio
Ordem de Servio
Hardware
Na garantia:
Metas de Tempo
5 minutos aps notificao, ou
baseado no tempo de recebimento do
formulrio ou e-mail.
Softwares que esto em contrato
recebero suporte, imediatamente,
na ordem de atendimento das
solicitaes de servio.
Servios que esto em contrato
recebero suporte, imediatamente,
na ordem de atendimento das
solicitaes de servio.
7 dias teis (aps notificao ser

contatado o fornecedor para despacho
do equipamento para manuteno. O
tempo de devoluo do equipamento
ao usurio depende do problema
relatado pelo fornecedor).
Fora da garantia:
5 dias teis (recebimentos, teste,

manuteno corretiva e devoluo ao
usurio).
Encomenda / No disponvel
30 dias teis
Conexes de Rede
Novos equipamentos para comunicao Se o equipamento deve ser adquirido

(por exemplo um hub, placa de rede, 30 dias teis.
Se o equipamento est disponvel.
switch).
24 horas.
Conexes de rede requerendo servios
especializados de cabeamento de rede
15 dias teis
Elaborao do projeto;
Licitao;
Execuo do projeto.
Transferncia
ou
realocao
de 2 dias teis
conexes de rede no mesmo ambiente,
com cabeamento prexistente.
Tempo Acumulado de
Indisponibilidade
Servios
No deve ultrapassar 20 minutos

mensais (Salvo por atualizaes)
Servidores
No deve ultrapassar 30 minutos
89
mensais (Salvo por problemas de

hardware)
Disponibilidade
Servios (WWW, FTP, Banco de Dados, 719 horas e 40 minutos mensais

AulaNet, BOTs, SMTP, POP3, outros) (24*30)-20 mim
Servidores (arquivo, impresso, outros)
719 horas e 30 minutos mensais

(24*30)-30 mim
Rede
720 horas mensais (100%), salvo,

por problemas de hardware, clausula
esta j definida nas linhas 4 e 5 desta
tabela.
Erros por Interface
Interface Entrada
5%
Interface Sada
5%
Local
Remoto
Servidores/Hubs/Switchs/Roteadores
Mximo 10s
Mximo 15s
Servio WWW
Mximo 15s
Mximo 20s
Servio FTP
Mximo 5s
Mximo 10s
Servio MAIL POP3 e SMTP
Mximo 5s
Mximo 10s
Servio Telnet
Mximo 5s
Mximo 10s
IRC Chat
Imediato
Mximo 5s
MySQL
Mximo 2 s
Mximo 5 s
PostGres
Mximo 2 s
Mximo 5 s
BOT
Imediato
Mximo 5s
Tempo de Resposta / Latncia

(Deve ter uma recepo interativa)
Disponibilidade do Link com Conexo 100% anuais, salvo, por problemas de

hardware, clausula esta j definida
Exterior (UFRGS)
nas linhas 4 e 5 desta tabela ou
problemas externos, neste caso por
exemplo, com a prpria UFRGS
Tempo para Recuperao de Falhas Linhas 2,3,4 e 5 desta tabela definem
Mean Time To Repair - MTTR
esta clusula.
90
Utilizao do Disco
Utilizao de Memria
Segurana da Rede *
Confiabilidade dos Dados
Infraestrutura da Rede
Problemas em Hubs, Switchs,
Roteadores
90%
Varivel de acordo com quantidade
de memria.
Seria necessrio extender tal tarefa a
outro prestador de servio.
100%
Resposta imediata (Salvo por

problemas j citados nas linas 4 e 5
desta tabela).
Tabela 9. Metas de Tempo.
* No tem segurana de rede deve-se considerar:

Controle de acesso;
Atribuio de usurios a classe de privilgios;
Definio de recursos;
Deteco de invaso;
Integridade de dados;
Atualizao dos dados;
Possibilidade de recuperao de dados afetados por hackers ou vrus;
Nvel de recuperao;
Tempo de recuperao.
Existem mtricas que variam de acordo coma aplicao e de acordo com o
usurio. Sendo assim nem todas a mtricas sero aplicadas a todos os
servidores/servios.
Alguns parmetros/mtricas, j foram explicados ao longo deste trabalho. No
entanto existem alguns que talvs tenham ficado meio obscuros. Abaixo se tem a
definio de alguns deles, ajudando assim no entendimento do trabalho.
Disponibilidade:
Medida geralmente como o tempo mdio entre falhas MTBF e o tempo mdio
para reparo - MTTR. Um exemplo, com no caso adotado neste trabalho, um MTBF de
99,5 % todo dia, significando que o downtime (tempo de inoperncia da rede) no
pode exceder 7,2 minutos a cada 24 horas.
Tempo de Resposta:
Mede o tempo para completar um pedido para um cliente, um grupo de clientes,

ou a rede. Algumas aplicaes como a WEB, exigem um tempo de resposta muito curto,
enquanto outras aplicaes com FTP, no so to restritivas. O tempo de resposta a
melhor medida para o usurio final.
Porm extremamente difcel medir o tempo de resposta. Aplicae smais
novas podem fazer diversas interaes cliente/servidor para terminar um pedido. Alem
disto, cada tipo d etransao pode ter seus prprios perfis e comportamentos. Tambm
dificel de localizar um problema quando os tempos de resposta so insatisfatrios o
problema poderia ser na rede, no servidor, no cliente, na aplicao, na localizao da
91
informao, ou uma combinao destes fatores.
Vazo:
Uma medida da quantidade de dados emitidos em uma quantidade de tempo

dada. Um exemplo seria uma palicao de vdeo conferncia, qure pode requerer mais
ou menos 384 Kbps a fim de fornecer a qualidade satisfatria. Descarregar uma pgina
de texto de um servidor WEB em dosi segundos requer vazo de 20 Kbps.
A aquisio de dados ser armazenada em arquivo de log e extrada em perodos
considerados de pico, ou seja, durante um ms (17/07 a 15/08 de 2001) nos turnos:
matutino das 9:00 hs s 11:30 hs, no turno vespertino das 14:30 hs s 17:00 hs e no
turno noturno das 21:00 s 24:00 hs. Estes sero coletados em intervalos de 1 hora, com
o auxlio das ferramentas descritas do captulo 3. No primeiro momento pensou-se em
realizar a coleta da sinformaes em intervalos menores, 5 minutos. Porm havia um
trafego muito grande de informaes na rede, inviabilizando esta periodicidade.
Utilizao do HD:
Configurou-se o snmptrap para enviar informaes com relao a carga de CPU

e memria. Primeiramente ser visto o script com relao a utilizao do HD.
Para isso foi criado um script que realiza o monitoramento da CPU e da
Memria, enviando ao administrador uma mensagem por e-mail e uma trap para o
dispositivo gerente quando a carga de utilizao atingir um valor pr determinado.
Estes scripts devem ser postos no cronw para que sejam executados em um
determinado perodo de tempo. Convm salientar que este perodo de tempo no deve
ser muito freqnte para no sobrecarregar o gerente.
O script da tabela 11, foi desenvolvido em C e deve ser posto no cronw do
agente, para que fique sempre em execuo. Ele utiliza o comando df para veificar o
estado atual do HD, em um perodo pr determinado no cronw. Neste caso ele ser
executado de 1 em 1h para no sobrecarregar a CPU. O comando df joga os dados
obtidos com o comando em um arquivo chamado temp (localizado neste caso no
diretrio /root/temp.), e ento realizada uma filtragem onde apenas o dado USE%
capturado.
Logo aps feita uma comparao deste valor com um valor pr definido, que
corresponde ao percentual crtico do HD, neste caso 90%. Caso a cota do HD chegue a
este valor uma mensagem por e-mail e uma trap so envidas. A mensagem chega para a
conta do administrador, neste caso mateus@floripa.com.br, e a trap enviada para
mquina gerente, neste caso mercurio.ucpel.tche.br. Esta trap assim que chega a
mquina gerente, no caso do Linux enviada para o arquivo syslog. No caso no
Windows estas traps so enviadas para o gerente que ao receber as traps as repass para
uma API de um console gerente. Poderia-se ter utilizado outros tipos de traps, caso
desejado. Utilizou-se apenas este tipo de trap (snmptrap p 164 -v1 200.132.45.44
public 1.3.6.1.4.1.3.1.1 parks 6 1') por significar que a entidade de protocolo de envio
reconhece que algum evento enterprise-especfico ocorreu (no caso HD FULL).
92
# include <stdio.h>
# include <stdlib.h>
int main (void)

{
FILE *fp;
char linha[1000];
char valors[10];
int i,t;
float valor;
valor =0;
system ("df > /root/temp");
fp=fopen("/root/temp","r");
if (fp==NULL)
{
printf("Erro");
}
else
{
fgets(linha,sizeof(linha),fp);
//while (!feof(fp))
//{
strcpy(linha,"");
t=strlen(linha);
for (i=0;i<t;i++)
{
if (linha[i]=='%')
{
sprintf(valors,"%c%c%c",linha[i-3],linha[i-2],linha[i-1]);
valor=atof(valors);
}
}
//}
}
if (valor>=90)
{
printf ("Alerta V2=%f\n",valor);
system ("cat /root/email.txt | mail -s 'Aviso HD FULL'
mateus@floripa.com.br");
system ("snmptrap p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1
parks 6 0 ''");
}
else
{
printf ("V2=%f\n",valor);
}
return(1);
}
Tabela 10.Script 1 - Estado do HD.
Utilizao de Memria:
O script da tabela 12, desenvolvido em C, deve ser posto no cronw do agente,

para que fique sempre em execuo. Ele utiliza o comando free para veificar o estado
atual da memria, em um perodo pr determinado no cronw. Neste caso ele ser
executado de 1 em 1h para no sobrecarregar a CPU. O comando free joga os dados
93
obtidos com o comando em um arquivo chamado mem (localizado neste caso no

diretrio /root/mem.), e ento realizada uma filtragem, atravs do comando free |cut
c 23-29, onde apenas os dados do campo USED so capturados.
Logo aps feita uma comparao deste valor com um valor pr definido, que
seria o percentual crtico de memria, que varia de acordo com o total de memria de
cada agente. No caso do host Parks utilizou-se o valor 64000 Kb. Caso a utilizao de
memria chegue a este valor uma mensagem por e-mail e uma trap so envidas. O
destino do e-mail e da trap o mesmo do script anterior, para verificar HD FULL.
# include <stdio.h>
# include <stdlib.h>
int main (void)

{
FILE *fp;
char linha[1000];
char valors[10];
int i,t;
float valor;
valor =0;
system ("free | cut -c 23-29 > /root/mem");
fp=fopen("/root/mem","r");
if (fp==NULL)
{
printf("Erro");
}
else
{
strcpy(linha,"");
valor=atof(linha);
}
if (valor>=64000)
{
system ("cat /root/email2.txt | mail -s 'Aviso MEM FULL'
mateus@floripa.com.br");
system ("snmptrap p 164 -v1 200.132.45.44 public 1.3.6.1.4.1.3.1.1
parks 6 1 ''");
}
printf ("MEMORIA:=%f\n",valor);
return(1);
}
Tabela 11. Script 2 - Estado da Memria.
Para serem aplicados a qualquer agente, os scripts devem apenas serem

modificados na sintaxe da trap, onde deve-se mudar o nome do dispositivo que est
enviando-a e a porta, neste caso a 164, para a porta de escuta do gerente, que por padro
a 162.
Os arquivos leitura.exe e memoria.exe, que so os scripts acima, foram
94
movidos para o diretrio root/scripts e adicionados ao cronw (/etc/crontab). No cronw

eles foram adicionados para serem executados de 1 em 1 h. Ambos necessitam que os
arquivos mail.txt e mail2.txt estejam no caminho definido no script (neste caso /root)
para que o e-mail de alerta seja enviado. A seguir pode-se observar o cronw de um
agente Linux:
# script de gerenciamento
05 * * * * root /root/scripts/memoria.exe
06 * * * * root /root/scripts/leitura.exe
4.5.3.9.2
Disponibilidade do Servio/Servidores (Manuteno Programada)
A manuteno da rede e servidores ser realizada, normalmente no final de

semana, visando minimizar qualquer inconveniente para os usurios. Se possvel, a
notificao do agendamento da manuteno ser com uma semana de antecedncia.
Reparos emergenciais podem causar interrupes de servio durante o horrio de
expediente. Aes imediatas sero tomadas para restaurar o servidor que est inativo.
Horas
Inco
Final
Domingo Segunda
0:00
0:00
24:00
24:00
Tera
0:00
24:00
Quarta
0:00
24:00
Quinta
0:00
24:00
Sexta
0:00
24:00
Sbado
0:00**
24:00
Tabela 12. Disponibilidade do servio
**
Ajustado
quando
(manuteno/atualizao).
4.6
necessrio
para
paralizaes
programadas
Aplicao da Metodologia de Medio de Dados
Como j visto na seo 4.5.3.8.2, uma metodologia de medio uma coleta de

dados que indica como esto sendo utilizados os recursos individuais do sistema, um
grupo de recursos do sistema ou o sistema como um todo. Essas informaes so
comparadas com a atividade posterior, para ajudar a determinar a utilizao do sistema e
a resposta do sistema a essa utilizao.
Ao criar uma metodologia de medio, iniciamos por identificar o recurso que
precisa ser medido. No trabalho em questo os recursos a serem medidos foram
definidos no captulo 2 e os parmetros/mtricas a serem aplicados a estes recursos
foram definidos na tabela 9.
Os parmetros/mtricas foram capturados com ajuda dos softwares WhatsUP e
MRTG. Aps a coleta e anlise durante um perodo aproximado de 28 dias, realizou-se
uma mdia de tais parmetros.
4.6.1
Relatrios Anlise dos Dados Coletados
A resposta adequada a uma situao especfica varia conforme cada cenrio. A

anlise apropriada, no apenas do sistema em questo, mas tambm em conjunto com a
atividade fim da instituio, auxilia a impor a soluo adequada para o problema.
Como j explicado os relatrios foram gerados diariamente atravs dos Logs do
WhatsUP. No entanto devido a alta periodicidade da gerao destes, (3 perodos dirios
em intervalos de 1 hora durante aproximadamente 28 dias), ficou invivel a publicao
95
de todos este Logs neste trabalho. Portanto ser demonstrado/exibido apenas o relatrio
final (mensal), como consta no contrato entre as partes - Mateus Casanova Pereira e
Universidade Catlica de Pelotas, o qual composto pelos mesmos tens do relatorio
dirio sendo este uma mdia dos mesmos.
Nota:
Como citado na seo 2.5, apenas alguns dos dispositivos sero includos no
SLA com sua total funcionalidade. Os demais apenas sero includos no contrato como
simples dispositivos, no existindo nenhuma mtrica para estes, a no ser a
disponibilidade operacional dos mesmos. Sendo assim, o no cumprimento do contrato
com estes dispositivos no implicara em nenum penalidade, salvo disponibilidade
operacional dos mesmos.
No anexo 6, apresentamos os dados coletados expressos sob forma de relatrios
e grfico relativos anlise dos parmetros/mtricas da tabela 9. E na seo 4.6.1.1
apresentamos as mtricas que no foram atingidas bem como a soluo para algumas
delas.
4.6.1.1 Mtricas No Atingidas no SLA
Ao observar os grficos e tabelas do anexo 6, nota-se que existema alguns

valores que no ficaram dentro das mtricas estipuladas no SLA (tabela 9).
A seguir tem-se as mtricas no atingidas e os motivos do no cumprimento
destas durante o perodo de anlise.
4.6.1.1.1
Ambiente Napi
Halley 200.132.45.46
Servio IRC Chat: Ficou indisponvel pelo perodo de 23 minutos e 17
segundos, enquanto o permitido era de no mximo 20 minutos/ms.
Servio IRC Chat: Ficou disponvel pelo perodo de 719 horas: 37 minutos e 46
segundos, enquanto o permitido era de no mnimo 719 horas: 40 minutos/ms.
O problema ocorrido com este servio foi devido a nova verso do Melange Chat
instalado, que ao contactar os desenvolvedores comunicaram sobre um bug do
servio, devido a incompatibilidade com o Service Pack 6a. Ao disponibilizarem a
correo, o problema foi resolvido.
Servio IRC Chat: O tempo de resposta/latncia de acesso remoto ao servio
IRC-Chat ficou 4 segundos acima do permitido, mais precisamente 9 segundos,
enquanto o permitido era de apenas 5 segundos.
O motivo deste atraso deve-se ao aumento do trfego da rede em 19 % acima do

valor normal, utilizado na elaborao das mtricas, durante o perodo de anlise.
No dia 04/08/2001 o servidor Halley, foi infectado pelo vrus Sircam/Code Red .
Para solucionar o problema, realizou-se a atualizao do servidor, atravs de um path
96
obtido na pgina da Microsot.

Leo 200.132.45.51
Servio Interface: Ficou indisponvel pelo perodo de 536 horas e 27 minutos,
enquanto o permitido era de no mximo 30 minutos/ms.
Servios WEB: Ficou indisponvel pelo perodo de 536 horas: 27 minutos e 49
Servio MySQL: Ficou indisponvel pelo perodo de 536 horas: 29 minutos e 06
Servio Postgres: Ficou indisponvel pelo perodo de 536 horas: 28 minutos e 1
segundo, enquanto o permitido era de no mximo 20 minutos/ms.
Servio FTP: Ficou indisponvel pelo perodo de 536 horas: 27 minutos e 59
Servio Interface: Ficou disponvel pelo perodo de 183 horas e 33 minutos,
enquanto o permitido era de no mnimo 719 horas e 30 minutos/ms.
Servios WEB: Ficou disponvel pelo perodo de 183 horas e 33 minutos e 11
segundos, enquanto o permitido era de no mnimo 719 horas e 40 minutos/ms.
Servio MySQL: Ficou disponvel pelo perodo de 183 horas e 33 minutos e 54
Servio Postgres: Ficou disponvel pelo perodo de 183 horas e 33 minutos e 59
Servio FTP: Ficou disponvel pelo perodo de 183 horas e 33 minutos e 01
O problema ocorrido com estes servios foi devido queima do HD deste

equipamento, que levou 22 dias at a chegada de outro para reposio.
Parks 200.132.45.43
Servio MySQL: Ficou indisponvel pelo perodo de 34 minutos e 07 segundos,
Servio FTP: Ficou indisponvel pelo perodo de 26 minutos e 12 segundo,
Servio Chat: Ficou indisponvel pelo perodo de 21 minutos e 36 segundos,
Servio MySQL: Ficou disponvel pelo perodo de 719 horas: 26 minutos e 53
Servio FTP: Ficou disponvel pelo perodo de 719 horas: 34 minutos e 48
Servio Chat: Ficou disponvel pelo perodo de 719 horas: 39 minutos e 24
O problema ocorrido com os servios MySQL e FTP, foi devido ao grande nmero
de acessos/requisies sofridos por estes no final de semestre. Neste servidor
localizan-se uma srie de ferramentas e aplicaes utilizadas na disciplina de
Gerencia de Redes, entre elas servios ligados ao banco de dados MySQL.
97
Quanto ao problema referente ao servio Chat, o motivo foi, devido ao fato de ser um
servio novo oferecido, e o administrador do servidor em questo (Marcelo Rios
Kwecko kwecko@atlas.ucpel.tche.br) ainda no possui pleno conhecimento sobre
tal servio.
Servio FTP: O tempo de resposta/latncia de acesso remoto ao servio FTP ficou
2 segundos acima do permitido, mais precisamente 12 segundos, enquanto o
permitido era de apenas 10 segundos.
Servio Chat: O tempo de resposta/latncia de acesso remoto ao servio Chat
ficou 3 segundos acima do permitido, mais precisamente 8 segundos, enquanto o
permitido era de apenas 5 segundos e o acesso local ficou 0,3 segundos acima do
permitido, enquanto este deveria ter um acesso imediato.
O motivo deste atraso deve-se ao aumento do trfego da rede devido o final do

semestre. Neste servidor localizan-se uma srie de ferramentas e aplicaes
utilizadas na disciplina de Gerencia de Redes.
MrBurns 200.132.45.177
Servio Interface: Ficou indisponvel pelo perodo de 39 minutos e 42 segundos,
O problema ocorrido com este servidor deve-se ao constante travamento do

equipamento. Este quipamento foi levado para manuteno vrias vezes onde trocouse memria, processador e atm mesmo placa me, mas no entanto os problemas
continuaram. Ao verificar o estado fsico do HD, constatou-se a presena de alguns
setores defeituosos. J foi realizado a encomenda/pedido de um novo HD para
substituio.
4.6.1.1.2
Ambiente POP
Hercules 200.132.45.54
Servio Squid: Ficou indisponvel pelo perodo de 37 minutos, enquanto o
permitido era de no mximo 20 minutos/ms.
Servio Squid: Ficou disponvel pelo perodo de 719 horas: 26 minutos, enquanto
o permitido era de no mnimo 719 horas e 40 minutos/ms.
As paralizaes do servio comearam a acontecer aps a instalao da nova verso do

sistema operacional da SUN. Para soluciona o problema, o sistema foi reinstalado.
Amadeus 200.132.45.60
Servio Interface: Ficou indisponvel pelo perodo de 1 hora e 48 minutos,
Servios WEB: Ficou indisponvel pelo perodo de 1 hora: 48 minutos e 26
98

Servios WEB: Ficou disponvel pelo perodo de 718 horas e 12 minutos e 34
O motivo destes atrasos, foi a compilao do novo Kernel do sistema operacional Linux
Conectiva 6.
Noe 200.132.45.31
Servio FTP: O tempo de resposta/latncia de acesso remoto ao servio FTP ficou
1 segundos acima do permitido, mais precisamente 11 segundos, enquanto o
permitido era de apenas 10 segundos.
Atlas 200.17.82.34
Servio Samba: Ficou indisponvel pelo perodo de 29 minutos e 39 segundos,
Servio Samba: Ficou disponvel pelo perodo de 719 horas e 31 minutos e 21
O motivo destes atrasos foram devidos a problemas de configurao na instalao de 2

novos laboratrios.
Switch 3 COM 200.132.45.254
Interface 13: Ficou indisponvel pelo perodo de 649 hora e 29 minutos, enquanto
o permitido era de no mximo 30 minutos/ms.
Interface 13: Ficou disponvel pelo perodo de 71 horas e 31 minutos, enquanto o
permitido era de no mnimo 719 horas e 30 minutos/ms.
O motivo para esta indispobibilidade da interface 13 deve-se ao fato desta ser apenas
uma interface de teste. Sendo habilitada apenas em tais ocasies.
Roteador Cisco 2511 200.17.82.62
Disponibilidade do Link com Conexo Exterior UFRGS: Ficou 40 minutos sem
conexo. A disponibilidade deveria ser de 100%.
O motivo foi devido a problemas Extra-UCPel, ou seja, o problema deu-se com a

prpria UFRGS, isentando assim as responsabilidades do servidor.
4.7
Proposta do SLA
Asseguir pode-se observar o acordo firmado entre as partes envolvidas, na

negociao do SLA descrito no decorrer do trabalho.
99
Universidade Catlica de Pelotas UCPel

Ser realizado um Acordo de Nvel de Servio SLA, entre o fornecedor
do servio - Mateus Casanova Pereira e o usurio Universidade Catlica
de Pelotas, onde fica acertado que o fornecedor deve gerenciar o ambiente
definido no captulo 2, atravs da adoo de algumas ferramentas j descritas
anteriomente.
Este acordo define expectativas de servios e responsabilidades de
suporte entre a Gerncia de Tecnologia de Informaes GTI e as demais
gerncias do sistema UCPel/RS, para suporte s estaes de trabalho
Windows 9x, servidores Windows NT, Servidor Linux, Hubs, Switch,
Roteadores, Impressoras relacionados, conectados a rede digital da
Universidade Catlica de Pelotas.
A assinatura deste acordo indica que a gerncia cliente e a Gerncia de
Tecnologia de Informaes revisaram e esto satisfeitos com o que este
acordo representa em termos de necessidades, apresentando objetivos
realizveis e mensurveis. Todos os itens citados na Tabela 9, devero ser
cumpridos. Caso o cumprimento de alguma das clausulas / parmetros
referenciados no sejam atendidas, o prestador de servio Mateus Casanova
Pereira estar sujeito a multa, ainda no definida entre as partes. Destaca-se
que o horrio de cumprimento de tal contrato da-se das 7:30 s 22:45.
Alm das mtricas da Tabela 9, outros termos devem ser observados:
9 Entregar um relatrio sobre o desempenho da rede no primeiro dia de cada
semana;
9 Minimizar o gargalo da rede;
9 Diminuir os pacotes descartados;
9 Melhorar o tempo de resposta da rede;
9 Diminuir o estado de inoperncia da rede, bem como de seus servios;
9 Reviso da rede a cada 30 dias, prevendo um possvel crescimento da
mesma;
9 Minimizar a super-utilizao de equipamentos (exemplo: servidores);
9 Neste caso, pode-se descentralizar tarefas executadas por um mesmo
servidor.
9 Caso o fornecedor do servio no cumpra com sua parte no contrato, ser
penalizado com multa pr-estabelecida no contrato;
9 Mesma clusula acima, aplica-se ao usurio.
_________________________________
Gerncia (Assinatura)
_____/_____/_____
_________________________________
Nome da Gerncia
_________________________________
Gerncia de Tecnologia de Informao
_____/_____/_____
100
4.8
O nvel total de servio definido por um conjunto de parmetros mensurveis,

cada qual tendo limites (thresholds) que so negociados entre o provedor de servios e o
cliente (usurio). Quando estes limites no so respeitados, normalmente existe algum
tipo de indenizao em favor do cliente. Em alguns casos, vrios degraus de limites
so definidos, cada limite correspondendo a um grau de indenizao entre o provedor do
servio e o cliente.
De acordo com Antnio Pimenta da ATL ALGAR Telecomunicaes [20], o
contrato de SLA deve conter as obrigaes da empresa contratada quanto aos limites
mnimos de qualidade dos servios oferecidos e as penalidades pelo no cumprimento
das obrigaes.
Normalmente, o SLA definido para cada tipo de servio contratado ou para cada
cliente, podendo haver acrscimos nos valores na medida que o cliente exige um SLA
mais ou menos exigente, variando neste caso os limites para cada um dos parmetros
citados no SLA.
Segundo Eduardo Winter, palestrante sobre SLA da IIR Conferences [35], o
valor dos servios ter um preo diferenciado de acordo com a qualidade de cada
parmetro exigida pelo cliente. Muitas vezes, determinada conexo mais importante
que outras, devido aos pontos interconectados ou ao tipo de dados trafegado. Portanto,
freqentemente faz sentido que existam conexes com diferentes parmetros
monitorados e diferentes limites configurados para cada um destes parmetros.
Claramente, percebe-se ento que os provedores de servios de rede necessitam
de uma estratgia, anlise e ferramentas de monitorao muito robustas. A
complexidade de monitorar e gerenciar mltiplos limites de parmetros em mltiplas
conexes apenas uma razo pela qual SLAs so to difceis de serem implementados e
principalmente cumpridos.
Atualmente, clientes corporativos de Provedores de Servios de rede procuram
por SLAs que ofeream fortes garantias quanto a verificao e anlise da performance
pela qual esto pagando. Da mesma forma, usurios internos das organizaes tambm
necessitam de informaes a respeito da utilizao e performance da rede.
Adicionalmente ao pr-requisito bsico de qualquer servio desta natureza
(disponibilidade), a habilidade de monitorar uma rede cada vez mais disseminada um
fator imperativo para as grandes redes atuais.
101
5 CONCLUSES E PERSPECTIVAS FUTURAS

Notou-se que nem sempre o tempo esperado aquele atingido. Muitas vezes
estipula-se um determinado valor, mas, no entanto pelos motivos mais variados, estes
no so atingidos.
Em alguns casos neste SLA proposto, o tempo atual de resposta, foi mais lento
do que o esperado, dado um certo ambiente do sistema. Nestes casos teria-se como
alternativa:
9 Alterar as mtricas do SLA, para que fiquem mais condizentes com a realidade;
9 Realocar recursos servios/usurios para outros servidores da rede que no
sejam to requisitados;
9 Adquirir sistemas adicionais visando diminuir a carga de trabalho sobre um
determinado servidor/servio.
A alternativa a ser adotada dependeria de uma situao especfica variando

conforme cada cenrio.
Ao analisarmos as mtricas no atingidas no SLA presente, pode-se propor
algumas solues para resoluo das mesmas:
a) A fim de evitar futuros problemas devido reposio de peas (como foi o caso
do HD no servidor Leo), prope-se um repositrio de peas vitais, as quais
suas ausncias indisponibilizariam o funcionamento de um servidor, como foi o
caso.
b) Em casos de instalao de servios ou atualizaes de servios ou sistemas,
durante o perodo em que se estiver trabalhando no servidor, distribuir suas
funes a outros servidores, evitando assim que eventuais problemas ocasionem
a paralisao dos servios oferecidos.
c) Analisando os papis desempenhados pelos servidores Atlas, Halley e Noe, os
contadores das mtricas estudadas, confirmam as necessidades de ampliao de
memria fsica e atualizao de processador destes servidores.
d) Analisando os papis desempenhados pelo servidor Parks e os contadores das
mtricas estudadas confirmam as necessidades de ampliao de memria fsica e
atualizao de processador deste servidor, ou ainda, simplesmente em perodos
que necessrio um grande poder de processamento (como ocorreu no final do
semestre) descentralizar/distribuir suas funes, ou seja, realocar alguns dos
servios oferecidos por este servidor para outro servidor com maior poder de
processamento.
e) O caso do MrBurns , enquanto o HD de reposio no chegar, repassar sua
funo de servidor de impresso pra um outro servidor.
f) Apesar dos percentuais relativos as mtricas de utilizao dos HDs dos
servidores Atlas, Tigre, Corvo, Mercrio, Terra, Ona e Triton estarem a baixo
do limite esperado, recomendamos a ampliao dos HDs dos servidores (em
especial dos quatro primeiros), pois os valores dos contadores em questo esto
prximos do limiar do gargalo de armazenamento.
g) Apesar dos percentuais relativos as mtricas de utilizao de memria dos
servidores Parks, Mercrio, Leo e MrBurns estarem a baixo do limite esperado,
recomendamos a ampliao de memria dos servidores, pois os valores dos
contadores em questo esto prximos do limiar do gargalo de memria.
102
O servidor Halley j atingiu o valor do contador limite, necessitando assim um

aumento de memria, a fim de evitar o atual gargalo.
A implementao de Acordo de Nvel de Servio SLA proposto, est
diretamente relacionado aos 7 itens descritos acima, como aes para soluo dos
gargalos de sistema identificados no ambiente de gerenciamento da UCPel. Atravs do
saneamento dos problemas descritos ao longo da seo 4.6.1.1 e do captulo 5, bem
como dos itens listados acima, pretende-se com a resoluo de tais problemas:
5.1
Minimizar o gargalo da rede;

Diminuir os pacotes descartados;
Melhorar o tempo de resposta da rede;
Diminuir o estado de inoperncia da rede, bem como de seus servios;
Minimizar a super-utilizao de equipamentos (exemplo: servidores);
o Neste caso, pode-se descentralizar tarefas executadas por um mesmo
servidor.
Concluses
O presente documento teve por objetivo apresentar os resultados finais

alcanados e perspectivas futuras do projeto para a disciplina de Administrao e
Gerncia de Redes de Computadores, cujo cunho foi analisar um ambiente de redes de
computadores, neste caso o da Universidade Catlica de Pelotas UCPel, empregando
as tcnicas de Organizao e Mtodos com o objetivo de estabelecer um contrato
usando Service Level Agreement SLA utilizando algumas ferramentas de gerencia,
para aquisio de dados necessrios s funes de gerncia.
Assim sendo, este documento apresentou o ambiente escolhido para o trabalho,
os requisitos para anlise do ambiente escolhido, as caractersticas das ferramentas de
gerncia de rede utilizadas, a metodologia de medio adotada, fundamentao terica
para anlise dos dados coletados, as solues propostas e perspectivas futuras e o
Acordo de Nvel de Servio SLA estabelecido.
No captulo 4 e 5, foram discutidos a mtricas que iriam compor o SLA,
enfatizando no capitulo 5 a soluo para o no cumprimento de algumas destas
mtricas.
103
6 BIBLIOGRAFIA
[1]
ALVES, F. M. Como aumentar a qualidade dos servios de manuteno

atravs de parcerias. In: IIR Conferences, 2000, So Paulo. [Apostila
para apresentao de Palestra]... So Paulo: [s.n.], 2000.
[2]
Brisa. Gerenciamento de Redes: Uma Abordagem de Sistemas

Abertos. Makron Books, 1993.
[3]
Brisa. Arquitetura de Redes de Computadores OSI e TCP / IP.

Makron Books, 1994.
[4]
Tereza Cristina de Melo de Brito Carvalho. Gerenciamento de Redes

Uma Abordagem de Sistemas Abertos. Makron Books, 1993.
[5]
Cisco. Disponvel por WWW em http://www.cisco.com (nov.2000).
[6]
INTERNET com certificado de garantia. EMBRATEL. Disponvel em:

<http://www.embratel.net.br/internet/info/gd-termos.html>. Acesso em:
Jun. 2000.
[7]
Management
INTERNET
ENGINEERING
TASK
FORCE.
Information Base for Network Management of TCP/IP-based
Internets: MIB-II. Disponvel em: <http://www.ietf.org/rfc/>. Acesso
em: Mar. 2000.
[11]
Internet Engineering Task Force. SNMP Version 3 (snmpv3).

Disponvel por WWW em http://www.ietf.org/html.charters/snmpv3charter.html
[12]
KORZENIOWSKI, Paul. Monitorando sua Rede. Artigo publicado em

revista. BYTE Brasil, So Paulo, dezembro de 1994.
[13]
Matrix. SNMPv3. Disponvel por WWW em

http://cpan.matrix.com.br/authors/Joe_Marzot/SNMP-3.1.0b1.readme.
(out.2000).
[14]
Meirelles, L.F.T. Uma Proposta para o Gerenciamento de

Aplicaes em Rede. Dissertao de Mestrado, UFSC. Santa Catarina,
1997. Orientador: Liane Tarouco
[15]
Meirelles, L.F.T. Apostila de MIBs e SNMP. Disponvel por WWW

em
http://redes.ucpel.tche.br/ensino/070020/html/apostila.html/
(nov.2000).
[16]
Meirelles, L.F.T. Apostila de Gerenciamento OSI.
Disponvel por
104
WWW em http://redes.ucpel.tche.br/ensino/070020/html/apostila.html/
(nov.2000).
[17]
Microsoft. Disponvel por WWW em http://www.microsoft.com

(out.2000).
[18]
MIBMaster.
Disponvel
por
http://www.equival.com.av/mibmaster/index.html
[19]
Neto, R.R.G. Implantando Gerenciamento de Redes com SNMP.

Projeto de Graduao, UCPel. Pelotas, 1999. Orientador: Alexandre
Timm Vieira.
[20]
PIMENTA, A. Terceirizao Versus Mo de Obra Especializada Prpria.

In: IIR Conferences, 2000, So Paulo. [Apostila para apresentao de
Palestra]... So Paulo: [s.n.], 2000.
[21]
Ramos, S. Q. Uma Metodologia para Anlise e Desenvolvimento de

Aplicaes de Gerenciamento de Redes de Computadores.
Dissertao de Mestrado, UFPE,1994.
[22]
REPORT Interpretation Seminar. Concord Communications Inc.

[Manual de Treinamento]... [s.n.], 2000.
[23]
SAID, D. Cuidando da rede de transmisso de dados. In: IIR

Conferences, 2000, So Paulo. [Apostila para apresentao de
Palestra]... So Paulo: [s.n.], 2000.
[24]
SIMPLE Network Management Protocol. University of California at

Davis. Disponvel em: <http://ucd-snmp.ucdavis.edu/>. Acesso em: Mar.
2000.
[25]
SLA Management Handbook. Telemanagement Forum NMF.

[Documentao para padronizao]... [s.n.], 1999.
[26]
CISCO
Systems.
SLA
Solution.
<http://www.cisco.com>. Acesso em: Dez. 2000.
[27]
SMART TMN Telecom Operations Map. Telemanagement Forum

NMF. [Documentao para padronizao]... [s.n.], 1998.
[28]
Soares, Luiz Fernando G. Redes de Computadores: das LANs, MANs

e WANs s redes ATM.Rio de janeiro, Campus,1995.
[29]
STALLINGS, W. SNMP SNMPv2 and RMON: Practical Network

Management. Second Edition. Addison-Wesley Publishing Company,
Inc., 1996.
WWW
Disponvel
em
em:
105
[30]
SURVEYS.
Lucent
Technologies.
Disponvel
<http://www.lucentnps.com/knowledge/surveys/00slm/>. Acesso
Fev. 2001.
[31]
Joel Issao Tanaka e Gilson C. Hotta Nishimoto - Estudo do

Gerenciamento de Performance para o Servidor NT da Celepar.
Disponvel
por
WWW
em
http://www.celepar.gov.br/batebyte/bb64/estudo.htm
[32]
Trger, A. Requisitos para Gerencia de Contabilizao de

Provedores de Servio Internet. Projeto de Graduao, UCPel. Pelotas,
1996. Orientador: Luiz Fernando Tavares Meirelles.
[33]
UCD-SNMP. University of California at Davis - Simple

Network Management Protocol. Online: URL
snmp.ucdavis.edu/ .
em:
em:
http://ucd-
[34]
VIEIRA, A. T. Implantao de Agente SNMP para Medio do

Trfego de Redes. Trabalho de Graduao Curso Anlise de Sistemas.
Universidade Catlica de Pelotas. 1997.
[35]
WINTER, E. Elementos determinantes para operao ideal do sistema de

manuteno da rede de telecomunicaes. In: IIR Conferences, 2000, So
Paulo. [Apostila para apresentao de Palestra]... So Paulo: [s.n.],
2000.
[36]
3COM. Disponvel por WWW em http://www.3com.com (out.2000).
[37]
RIBAS, Jlio Csar da Costa Ribas. Acordo de Nvel de Servoo.

Florianpolis 2000.
106
ANEXOS
Anexo 1 Ambiente de Gerenciamento NAPI

Anexo 2 Ambiente de Gerenciamento POP
Anexo 3 Arquitetura Funcional do Ambiente de Gerenciamento
Anexo 4 Exemplos de Traps Recebidas pelo Gerente
Anexo 5 Resposta ao questionrio SLA
Anexo 6 Relatrios do SLA -NAPI e POP

Proposta de Gerenciamento

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Proposta de Gerenciamento

Загружено:

Авторское право:

Доступные форматы

Universidade Federal de Santa Catarina

Departamento de Informtica e Estatstica INE

Administrao e Gerncia de Redes de Computadores

Mateus Casanova Pereira

Professor: Carlos Westphall

Gerncia de Redes de computadores........................................................................ 5

Principais Arquiteturas para Gerenciamento de Redes ................................................. 6

reas Funcionais de Gerenciamento de Redes........................................................ 8

Axiomas de Gerenciamento de Redes .................................................................... 11

Concluses do Captulo ........................................................................................... 11

AMBIENTE DE GERENCIAMENTO ESCOLHIDO.........................................12

Especificao e Implementao de um Sistema de Gerenciamento .................... 16

Anlise de Hardware e Software ............................................................................ 19

Concluses do Captulo ........................................................................................... 34

SOFTWARES DE GERENCIAMENTO ..............................................................36

Plataforma de Gerenciamento ................................................................................ 36

Softwares de Gerenciamento .................................................................................. 37

Arquitetura Funcional do Ambiente de Gerenciamento...................................... 63

Concluses do Captulo ........................................................................................... 63

SLA - Service Level Agreement ............................................................................64

Gerenciamento de Nvel de Servio SLM ........................................................... 64

Coexistncia entre SLA e QoS ................................................................................ 65

Abrangncia de SLAs nas Empresas...................................................................... 65

Fundamentos para Anlise e Medio ................................................................... 70

Aplicao da Metodologia de Medio de Dados.................................................. 94

Proposta do SLA ...................................................................................................... 98

Concluses do Captulo ......................................................................................... 100

CONCLUSES E PERSPECTIVAS FUTURAS...............................................101

Concluses .............................................................................................................. 102

Em decorrncia das vantagens que as redes de computadores oferecem, o nmero

Gerncia de Redes de computadores

As facilidades providas pelas redes tendem a estimular o crescimento das

tempo e recursos. Em redes de longa distncia, a tarefa de gerenciamento

Principais Arquiteturas para Gerenciamento de Redes

A exemplo do que ocorre com os demais temas da rea de redes, as diferentes

Os agentes se comunicam com os gerentes atravs de um protocolo de

por agentes e disponibilizadas para um ou mais gerentes.

gerenciamento em seus equipamentos, portanto estas informaes podem ser

reas Funcionais de Gerenciamento de Redes

A arquitetura de gerenciamento OSI define cinco reas funcionais para prover

restabelecer as unidades do sistema que venham a dar problemas.

atravs de parmetros estatsticos como atrasos, vazo, disponibilidade e o nmero de

Figura 1. Mensagens num Protocolo de Gerenciamento Fonte: [4].

Axiomas de Gerenciamento de Redes

Neste captulo foram descritos os principais conceitos relacionados ao

2 AMBIENTE DE GERENCIAMENTO ESCOLHIDO

Figura 2. Estrutura Organizacional.

Artigo 50 - O Conselho Coordenador do NAPI constitudo pelos seguintes membros:

vii) divulgar as aes e contribuies do NAPI;

Atualmente a UCPel possui um total de 20 servidores ativos em seu quadro. A

Tabela 1. Recursos Humanos UCPel.

Especificao e Implementao de um Sistema de Gerenciamento

Um Sistema de Gerenciamento de Redes (SGR), pode ser visto como um centro

Figura 3.Sistema Gerente e Sistema Gerenciado - [16]-Utilizao Parcial.

Escolha do Servidor - Gerente

Atualmente na hora da escolha de um servidor, pode-se optar por usar um

Pentium 350 MHz

Tabela 2. Servidor Gerente.

Sistemas Operacionais da Rede

Aps a escolha do ambiente de rede, deve-se escolher o tipo de sistema

2.4.4.1 Monitoramento de Trfego

a adoo de alarmes e a utilizao de inmeros acrnimos.

Anlise de Hardware e Software

Como j citado anteriormente o ambiente de gerenciamneto ser constitudo pela